I am writing an independent WatchOS App that uses CoreLocation. I want to ensure that location updates are never paused. Apple defines pausesLocationUpdatesAutomatically here, which is exactly what I was looking for. The only problem is that it is not available for WatchOS apparently. In an iOS app it is available. Once I realized this, I checked in CLLocationManager.h and it isn't there at all.
Then I found on a Microsoft site of all places (Xamarin) that it is unavailable for WatchOS apps, and is available for iOS apps.
How can I find info like this either from Apple's docs or in the header files...this is pretty confusing to me. It was not clear to me on the Apple website that this would be unavailable for a WatchOS app.
On the Apple page you linked to, look at the list of SDK's on the right - This property is only available on iOS after 6.0 and Mac Catalyst after 13.0.
If an SDK isn't listed (watchOS) then it isn't available on that platform.
Related
I have implemented SIWA natively on iOS, however it is only offered on iOS 13+. Is there a way to do an iOS 12- fallback SIWA in a webview? I am having trouble finding any examples of this.
Sign in With Apple doesn't make the whole app incompatible with iOS 12 or lower (the same is for SwiftUI).
If you want to support Sign in With Apple on older versions of iOS (as well as the non-iOS platform) you can use Sign in with Apple JS framework.
Useful link: https://forums.developer.apple.com/thread/119198
I am working on an iOS app that integrates with multiple bluetooth devices (e.g. printers and barcode scanners). Each of the devices comes with it's own version of SDK and most of them just have objective-c/swift SDKs but not javascript SDKs.
Would like to find out what is the best way to reduce the app bundle size at the same time supporting multiple devices ?
Based on my investigations,
iOS doesn't allow downloading objective-c/swift code dynamically during runtime, hence the option of downloading the SDKs after the user having installed the app is ruled out.
Would like to get a feedback on the feasibility of the below solution. Also let me know if there is a better solution.
iOS version 8+ support embedded frameworks - Have separate iOS driver
apps for each of the supported devices which just installs the device
SDK as a shared embedded framework so that the parent app can
dynamically link to the shared embedded framework if one that matches
the connected device is available, otherwise force the user to
download the respective driver app.
This question has gone unanswered for a little while, so you may have already figured this out, but no, you cannot make shared embedded frameworks on iOS. Only Apple can do that. All of the frameworks you use must be either provided by Apple or embedded inside your app.
I'm running the beta version of iOS 9 on my phone.
I downloaded my app from the App Store and it works.
When I install it from Xcode it doesn't work (since it is not supporting ATS).
How can that be?
When introducing features in new iOS versions Apple often checks for the link time or SDK version of the app.
Applying new rules only to apps that are linked to iOS SDK 9 for example, they can enforce the rule on new builds, where the developer should be aware of the rule. Old apps are left alone and keep working as before.
The version from the App Store is likely linked against an earlier SDK version. Apple determines behavior for some things like UI and, AFAIK, ATS, by looking at the linked SDK version.
Apple notices that App Store version is linked against an SDK version that doesn't know about ATS and enables legacy support. But your version compiled in Xcode is linked against a SDK version that does know about ATS and Apple therefor enforces the rules.
I searched online extensively but could not find any concrete/official information on the following questions related to submission of an app affected by ATS.
Q: ATS is applicable only on iOS 9 onward. What happens to older apps (built for iOS 8.x and below) when the device is upgraded to iOS9. Will they have ATS disabled by default or will they stop functioning if they are not ATS compliant?
ANS: Apps built for lower SDKs will opt-out of ATS by default. Was able to verify this using an iOS 9 beta 5 device.(app-dev-forum link)
Will applications that set the global ATS disabler flag (allowarbitraryloads) be admitted to the app store?
After iOS 9 releases, can apps linking to older SDKs can still be submitted to the marketplace? Apple is currently accepting apps with deployment_sdk of iOS 5
After iOS 9 releases, should apps be built with the release version of the SDK?
Q: I heard that if an app is built against beta versions, it will be rejected. Please correct me if I'm wrong.
ANS: Yes. Apps based on beta version of SDKs will get rejected.
Great if you can answer any of the above. I'll compile the answers in this post to make it easy for later reference. Would be great if you add any official links for ref. Any help is really appreciated.
As you said in your updated question, pre-iOS-9 apps are unaffected by ATS, because it only applies to apps linked against the iOS 9 (or later) SDK.
Yes. Disabling ATS globally is fine as long as there's a good reason for doing so.
With iOS 8, I think Apple started requiring apps to be built against the iOS 8 SDK about five months after iOS 8 shipped. So Apple might require you to build against the iOS 9 SDK at some point. Or maybe not. It's anybody's guess.
Yes, iOS apps should be built against the iOS 9 SDK at this point. Linking against the iOS 9 SDK probably won't be required (at least initially), but it is usually a good idea to keep up-to-date.
Yes, you must build against the final iOS 9 SDK version rather than any previous iOS 7 beta SDK.
Some of my answers are based on a personal experience, some on openion and some on documented apple guide lines.
It will not function on iOS 9 device.
From a personal experience. I had live app. that was functionning
perfectly in iOS 8.2 devices and once iOS 8.3 got released and those devices updated the App.
suddenly start crashing.
Set the ATS flag, build with iOS 8 (Xcode 6.X) and submit to the store.
PList is just a text file. It always can have non-recognized items by apple. As we always add values there for 3rd party libraries. I strongly don't think that apple's "current automated checker" will or supposed to check a future flag. and they will function for iOS 9 for the same reason app start crashing on point one!
Yes. Those should include the ATS flag. Otherwise, will be rejected.
Apps that do not perform as advertised by the developer will be
rejected. (2. Functionality 2.3)
NO.
Not applicable to force all developers to update their enviroment.
They only have to add the flag. Apple never did such a sudden
restriction.
True.
Refere to this answer. that shows a screen shot here.
Does anyone knows if there is a document from Apple that states what iOS SDK version you have to use for building your app to upload it to iTunes Connect?
I often read in blogs "only the latest", but I need this official from Apple because our vendor wants to build against the iOS 4 SDK because of "strange errors with iOS 5".
I'm not sure if this is OK. We want to run the app to run on iOS 4 and 5.
I too had read what you had—that the latest SDK had to be used... Yet, I haven't found an official source for this now I go looking for it.
Using the iOS 5 SDK does not prevent you from having a build target of iOS 4.2 (or similar), which will it to run on both iOS 4.2+ as well as iOS 5. Perhaps a good starting point is educating the client that there is a fundamental difference between the iOS 5 SDK and iOS 5 itself—they may well just be reacting to media coverage of iOS 5 issues like battery life.