I have not tested whether this can be done in an NSE. Various extensions have differing sandbox limitations on what functionality would be enabled. That's why I suggested to try it out yourselves as an experiment. While you won't be able to send actual push notifications using a free account, you can use a JSON file containing your payload in the simulator. This will still let you test your AlarmKit interaction inside the NSE, and at the very least let you know if this is a viable architecture to consider. You would create a JSON file as such: { "Simulator Target Bundle": "com.airraidapp.test", "aps": { "alert": { "title": "Airraid Update", "body": "Airraids are over" }, "mutable-content": 1 } } and call it airraid.apns (or whatever you want, just match your BundleID in the payload to your app) And then either drag and drop this onto the simulator to simulate a push, or use xcrun from a Terminal. xcrun simctl push --help shows the usage. Good luck! -- S.Beck -- 7strikes.dev

This would be possible to architect through a push architecture rather than trying to poll your server, but all that will depend on whether you can set/cancel/modify alarm kit alarms from within a Notification Service Extension. I would suggest to write a quick sample receiving push notifications in an NSE, and see if you can manipulate the main app's alarms from there. If that works, you can architect this by controlling the alarms by sending push notifications based on the air-raid status. -- S.Beck -- 7strikes.dev

Bluetooth Low Energy (BLE) compatibility concerns with A16-powered iPads are frequently reported. A review of these forums and broader online resources yields numerous references to such issues. But in your case the issue is stemming from your side. Apple explicitly says ADV_DIRECT_IND should not be used in Accessory Design Guidelines. Your implementation may have worked in many cases, but deviating from specifications and recommendations can cause such unforeseen issues. The technical reasoning for this limitation should be obvious. Apple devices roll their Bluetooth addresses periodically, and a directed advertising to an address that is no longer in use would have nowhere to go. While you can use the permanent identity address in the advertising for a paired device, that requires your accessory to decode the random address using the IRK, which I am guessing it no longer has in DFU mode. What Apple will say about this remains to be seen, but I would say "ADV_DIRECT_IND should not be used" is something they already have said. -- S.Beck -- 7strikes.dev

Authorization needed for the significant change is indeed a bummer. But Apple does recommend to start with the minimum authorization you require, and then escalate if needed. "Your car sucks!" as an excuse would be a valid reason for a user, IMO. Significant Change will only return WiFi/Mobile tower based locations, and won't even have altitude. Once you have an approximate location, you can either use a DEM to estimate the altitude, or use requestLocation(), which is the same function as startUpdatingLocation() but with an internal 10 second timeout, which BTW is how long your app will be running after a significant change wake. If the system can get a fix, the last location you will be sent (you can get multiple) will hopefully be accurate. As you can always end up with a stale location, checking the timestamp is always a good idea. All of the location updates for continuous updates, significant change, and requestLocation will come through the same callback. If the CLLocation.verticalAccuracy is zero, then the location is likely from a non-gps source. BTW, have you looked into comparing ellipsoidalAltitude vs altitude? In case the problems with some cars is not the quality of the data but using conflicting systems (WGS84 vs MSL)? -- S.Beck -- 7strikes.dev

Two little facts that might prove useful: when you instantiate a location manager and start updates, the system will usually (but unfortunately not always) first send the latest cached location so the app has a starting point while a GPS fix is pending. You can detect this by checking the CLLocation timestamp against the time your app started updates. Although it wouldn’t be guaranteed (and maybe that’s worse than nothing) it could be another data point although not the ideal solution, using significant location change API would keep sending you updates in the backgroun, and along with requestLocation() you could be keeping a tally of locations and altitudes before CarPlay gets involved. Unfortunately without access to raw data and the DEM, tricks like this seem to be the only remaining solution.

Altitude data from vehicles can be notoriously wrong, due to using different reference frames and then not bothering to report which they are using. Most of the time the issue is caused by the difference between WGS-84 and MSL (Mean Sea Level), and iOS then having to guess what's what. While there isn't a way to ignore vehicle sourced data while connected to CarPlay, there is a way to detect if the data is coming from the phone GPS or not. CLLocation.CLLocationSourceInformation will tell you if the source is external. Once you know that, the workaround would be: If you can, store the altitude you have before CarPlay is connected Once CarPlay connects, if you notice a jump in altitude, and the values you are getting are relatively sane, you can add/subtract as needed to get the correct(ish) value. If the values are crazy, jumping up and down, then you could use CMAltimeter instead, that is based on the phone barometer and will not rely on CarPlay. CMAltimeter is likely to lag behind, but probably useful enough if you are in a car and not in a rocket, and if you can source a DEM, also probably predictable. It is also likely to be somewhat wrong depending on how good the door seals are in the car. One can hope that if they have good enough door seals to throw a barometer off, then they have a proper nav system that gets the altitude correct. -- S.Beck -- 7strikes.dev

While the answer to the why? is best left to Apple, it is rather established that iOS (and macOS since the unification DTS Engineer mentioned) only allocates roughly 50% of the Connection Interval to the Connection Event. As you have also noticed, the event closes on a timer. The iOS Bluetooth stack strictly caps the connection event length, typically allowing a maximum airtime of around 6.96 ms. If your Connection Interval is set to 15 ms, this caps your radio usage to roughly 46% to 50% of the interval Additionally the Connection Event Length can be truncated further if the radio(s) are otherwise occupied, and co-existence becomes an issue. That is probably the variance you see in the best case vs. usual case scenarios. Connection Event Length (max_ce_length) cannot be negotiated, so your only remaining option would be to work around it. While it might seem counterintuitive, using a longer CI might give you a better throughput by reducing the ratio of dead air (T_IFS: Inter Frame Space), although I suspect the ratio of CEL might also drop. I think this is also something you have observed. If your solution you seek is raw throughput, you may have looked into L2CAP, which will help, but I suppose that is not the question at hand today. -- S.Beck --- 7strikes.dev

Have you tried installing the debug profile for Nearby Interaction to see if that will give you low enough level logs to see what's going wrong? -- S.Beck -- 7strikes.dev

There are technical limitations of such a filter (your app is woken up due to an NFC field-level signal before any AID information is exchanged), and there is the meaning of a default, as in there can only be one. Whether a limited purpose app should be the front facing app or not is a user selection, it will be their decision to whether choose your app for the limited use, or another app for general use. -- S.Beck -- 7strikes.dev (I have some detailed opinions notes on this subject)

All you need to know about applying for and starting to use SensorKit is explained at Accessing SensorKit Data As for the wavelengths, those are properly documented, but you need to study the API documentation for it. Series 9 uses a range of 525 - 940 nm, and the exact wavelength used in the sample will be part of the PPG data you receive. SRPhotoplethysmogramOpticalSample lists all the data points you will receive. -- S.Beck - 7strikes.dev PS: check my article about the required hold period of SensorKit data once you start using it, so it doesn't come as an unpleasant surprise

While you can read multiple tags without restarting the session (invalidateAfterFirstRead: false will let you do that), but your use case sounds like you are trying to use the wrong tool. iBeacons or a custom Bluetooth tag are what these kinds of applications are for. What I would say is: both approaches are problematic, because... Voiceover will announce a new session with every session, and that would become annoying quickly there is no "Live Mode" you can create, the sessions will timeout, and even worse... not only this drains the battery, but causes heat buildup on the NFC antenna (reading is not passive). So, not only you have no chance of keeping a session active for minutes, repeatedly starting sessions will increase the thermal stress and the sessions will start getting shorter and shorter, and eventually stop for cooldown. I would say, don't do it. -- S.Beck - 7strikes.dev (I have a more detailed article about this)