10 Oct 2021 UPDATE:  Still waiting on Apple. There’s a handful of developers that are having the same issue as me and we’ve been told that they’re still working on it. But that’s all the info I get. And I check every week. I suspect that Apple’s more worried larger issues with the latest iOS/IPadOS/watchOS release and once that settles down they’ll address my issue. Of course that’s just a guess since they are so limited with information. Frustrated is not strong enough a word for this situation as I completely powerless to do anything. It’s completely in Apple’s court. I explored whether to reissue the App under a different name but ultimately that would be too confusing and abandoned the idea. So we wait.

04 Sept 2021 UPDATE – Still waiting on Apple. Ugh! I wish I had a better update. The crux of the problem lies with how the App Store identifies AltitudeAlert. Let me explain. AltitudeAlert has two unique identifiers that The App Store requires for authentication whenever an update is submitted for distribution to the public. One identifier is used to authenticate the iOS/iPadOS version (iPhone/iPad). The other identifier is used to authenticate the watchOS version (Apple Watch). Somehow, and unbeknownst to me, the identifier for the watchOS version was changed on the current watchOS version running in the App Store. According to Apple, this isn’t possible once an app update has been approved. Furthermore, I’m prohibited (as the app developer) from changing the app identifiers once the first version of the app has been approved. So how can this happen then you might ask? Good question! I don’t know either. And it appears that Apple isn’t sure either. In any case, the App Store software engineering team is researching the issue and that’s the only information that I’m being given. So where does this leave us? Honestly, I’m not sure. I’m drawing up some contingency plans. Worse case, I will have to resubmit the app to Apple as a new app with new identifiers. This would be a big problem due to the active subscriptions running. I’m not sure how this could be handled, mostly because Apple controls the subscription process and I have no access to user info (other than encrypted purchase receipts that are used restore subscriptions). Another option would be to remove the Apple Watch from the app (since that’s the offending identifier). I’m not sure Apple would even allow this without submitting the app again as a new app. At some point, if this process drags on too long, I will execute one of these contingency plans. I’m not there yet and hope that Apple gives me some guidance (or a solution) soon. So that’s it. Thanks for being patient through this process. I’ll post another update soon one way or the other.

15 Aug 2021 UPDATE – I was hoping to have the issue with Apple resolved by now but they’re still researching the problem. I’m still optimistic and hope to have this resolved soon. Thanks for your patience.

08 Aug 2021 UPDATE – The issue has been resolved and I’m waiting on Apple to distribute the update. There’s a glitch in their processing and we’re working through it. I’m optimistic that it will be resolved in a day or two.

I’ve identified an issue in the Navdata database that renders all published waypoints invalid. This issue is the result of the FAA deprecating the Navdata file type that AltitudeAlert uses. I’m working on an update that will utilize multiple Navdata file types and will have an update out as soon as possible. A short term workaround is to manually enter the published waypoint via the User Defined Waypoints section. See the User Guide for details.

If you have a question, comment or suggestion.  Please fill out the contact sheet below.


Double check your email address.  From time to time I get an invalid address and I’m unable to respond to it.