<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Example: the iOS Keychain APIs do not support access groups on the simulator, so if you try to make a keychain query that targets an access group, you get no results. This means that in order for my app to operate correctly on simulator, I need to pass different parameters on simulator and device. This is an unfortunate distinction that ideally should not exist in a simulator, but unfortunately such cases do exist.<div><br></div><div>(This was at least true in iOS 9, and I haven’t seen any indication that it has changed.)<br><br><div id="AppleMailSignature">-BJ</div><div><br>On Oct 26, 2017, at 5:43 AM, Karl Wagner via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div class="">I’m currently -1 on this, because I don’t think simulator/device is a worthwhile-enough distinction for a built-in condition.</div><div class=""><br class=""></div><div class="">- Are you maybe looking for a Debug/Release condition? Because we already have that, through compile-time variables (the “-D” option).</div><div class="">- Does your platform’s simulator/emulator expose any additional API? Great! Take a look at #canImport…</div><div class="">- Why else would you need to distinguish simulator/device, and why are OS and architecture not sufficient for that case?</div><div class=""><div><br class=""></div><div>Karl</div><div><br class=""><blockquote type="cite" class=""><div class="">On 25. Oct 2017, at 05:05, Graydon Hoare via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Hi,</div><div class=""><br class=""></div><div class="">I'd like to propose a variant of a very minor, additive proposal Erica Sadun posted last year, that cleans up a slightly messy idiomatic use of conditional compilation in libraries. The effects should be quite limited; I'd call it a "standard library" addition except that the repertoire of compiler-control statements isn't strictly part of the stdlib.</div><div class=""><br class=""></div>Proposal is here: <a href="https://gist.github.com/graydon/809af2c726cb1a27af64435e47ef4e5d" class="">https://gist.github.com/graydon/809af2c726cb1a27af64435e47ef4e5d</a><div class=""><br class=""></div><div class="">Implementation (minus fixits) is here: <a href="https://github.com/graydon/swift/commit/16493703ea297a1992ccd0fc4d2bcac7d078c982" class="">https://github.com/graydon/swift/commit/16493703ea297a1992ccd0fc4d2bcac7d078c982</a></div><div class=""><br class=""></div><div class="">Feedback appreciated,</div><div class=""><br class=""></div><div class="">-Graydon</div><div class=""><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></body></html>