So far, my users where notified in the app without me having to do anything but call takeOff and (well here i'm not sure if this was necessary) use a few arbitrary checkpoints. They could choose wether or not they want to update their app now, later or never.
BUT apparently this has stopped working over the past few weeks, I'm receiving more and more feedback that the only way they got to know that there is an update available was through the email that is sent to them by TestFlight.
Did they replace this with "force-upgrade"? In-app update with TestFlight on iOS mentions that using force upgrade enables notifications, yet it forces them to update, which is not what i want.
Or has this something to do with the SDK 2.0 struggling with iOS7?
It's an iOS 7 issue. We're working on work arounds. Here's a help article that explains it more: http://help.testflightapp.com/customer/portal/articles/1318463-in-app-updates-are-not-working-on-ios-7-what-should-i-do-
Related
Im developing an SDK and its deployment target is set to 9.0. Im using some API's that are deprecated in iOS 10 and above and others that are deprecated at iOS 13 and above.
My question is what will happen to an app that is consuming my SDK and its deployment target is set to iOS 14? will my SDK be affected? will my methods get properly invoked? will it crash the hosting app? is the behaviour under these circumstances is unclear? or maybe all will run perfectly?
Any light on this would be appreciated, thanks.
First things first, deprecation is the first step in the process of ending the life of an API and Apple is warning the developers that these APIs will be removed in one of the future iOS releases. Nobody knows when except Apple. There is certainly a wisdom in that (e.g security concerns, better API design, etc).
Developing an SDK which uses deprecated APIs is generally considered a dead end. I am sure you have your own reasons, however, anyone who uses your SDK will be asking themselves whether there will be any value or will there be a maintenance overhead.
There are certain issues during the development stage that you should be aware of. If the app developer of an app who uses your SDK sets the deployment target to iOS14, most probably Xcode will flag this up as a warning. It depends on other things such as the development language that you are using, whether it is already compiled etc.
Assuming there is a good reason for you to move forward, there are several scenarios on what could happen.
In Production, the very short answer to your question is, the application will crash if the API is removed in the next OS upgrade by Apple (if the app developer doesn't take any action before it is released). However, long answer is a little bit more complicated than this.
The best case scenario is Apple doesn't remove the API for a very long time e.g UIWebView. I think it has been at least 5 years now since Apple deprecated the framework, and technical you can still build an app with the UIWebView. That means you do not have to do anything (in theory).
However, if the API is removed by the new OS update, there are several scenarios:
The device is eligible for an OS upgrade, THEN the app will most likely keep crashing when the API is called by the app/sdk.
If the device is NOT eligible for an OS upgrade (e.g stuck on iOS 10), the app will still live for a while on these devices until the owner buys a new device (whether the app developers takes action or not). That particular app version should also be available through iCloud purchases/downloads. So customers can re-download that version even if they delete it etc.
For an active app developer, the first scenario shouldn't happen. I would expect them to test the app on the next beta of the OS version and take action if there is an issue e.g ask you to provide an update, or replace your SDK with another one.
The API removal process can be a little bit more informed and Apple might force your hand, but be still gentle. Apple may make it explicit and warn developers that any new apps, or app updates which contain the API will not be accepted to App Store. This ties the app developers hands. They need to make a choice. This warning would be months in advanced and you would put this work into your backlog and plan for it.
The scenario in bullet point 2, on the other hand, may not be obvious at first, and Apple is doing a pretty good job of convincing the customers to buy the latest devices. There is a relative 2 year cycle, so you may not find many customer using older phones which are stuck on older OSs. This may be ignored depending on your significance level.
The app developers may or may not be able to keep the min target of the app. If they are so adamant then most likely their app will not be compatible with the latest devices or Apple may refuse their updates (as above). Then that means it is pretty much the end of life of the app, only used by a handful of customers.
There is also scenario where Apple may also remove the applications from App Store and iCloud download which are not maintained for a certain period of time (this has happened).
I have a paid app that was released on iOS 4. It hasn't been updated and I'm now reworking it to work with iOS 10. Since in app purchasing was not a thing, I made a free (lite) and paid version of the app. I would like to update the paid version to iOS 10 and change it from paid to free with ads and an in app purchase to remove ads.
I tried researching various methods and I have not found a fool proof way or evidence that one will work in all cases. The two most prevelant methods I found:
Use an existing UserDefaults key value to determine if they opened the old app and then grant them no ads in the new version.
I don't think this method will work, as if the app was uninstalled or the user redownloads it after the update they would not have that value.
I believe iOS 7 offered receipt checking. Use receipt checking to determine if the user has paid for the app and check if the date is before the new version date.
I'm not sure if this would work either. I saw in the documentation to verify locally. Would everything I need exist if the app was an iOS 4 app originally? Would this work for users who had the app through a promo code? What if they don't have an internet connection at the time they open the app? I had trouble finding sample code for this option to test.
How would I go about doing this? Are any of the methods above the only way or are there others?
Out of all the resources I found on this subject, checking the receipt seems to be your only feasible choice. If you have an account where you purchased your app, you can run the new version of the app via Xcode with that account and see if the receipt validation gives you the expected information. Though installing the app via Xcode may alter the receipt that the account has, you may want to check on that.
NSUserDefaults option could work if you were setting any value to NSUserDefaults on the iOS 4 version.
I've seen solutions like AppHub that allow changes to an already-published iOS App without submitting an updated version to the App Store but as far as I know it doesn't support Xcode. Are there any others that are similar to AppHub that support AppCode and Swift?
My reason behind this is that I am making an app for my school and don't like using WebView. There is an announcements tab that needs to be updated daily but to submit an update to the App Store takes a couple of days.
If you are adding daily news to your app, putting a new version on the App Store every day is definitely not the way to go. Look into a backend service like Firebase or AWS to deliver content updates without the need for the user to update the app daily to see them.
I'm new to iOS development, and my problem is that the latest iOS update (8.0.2 at the time of writing this) causes my app not to work properly. My app is already for sale in the app store, so any user who has already upgraded to the newest iOS version is downloading a broken app. I have a plan for fixing the bug, but the turnaround time for new releases is quite slow, and I don't want to screw over all the new users while I wait for the updated app to get approved.
What should I do?
I know I can set the "Deployment Target" in Xcode, but this does not seem to prevent users with the newer iOS from still buying it.
Today:
Fix your app as quickly as possible (that turnaround is only about
you)
Submit it to Apple
Request an expedited review request review to Apple, explaining why you need a quick turnaround (critical bug fix is a valid reason). You can't abuse of expedited reviews, so use them carefully.
In the future:
Before Apple releases a newer iOS version, they release developer previews. You need to use these to make sure your app will run smoothly when the newer iOS is released to the public.
When contacted by a customer who is experiencing a problem in your iOS app and making an update to fix it, is there a way to get the user to verify the fix privately before making the update available to everyone?
Background: I was contacted by a user who is seeing a weird rendering problem since installing the latest update. Unfortunately I have not been able to reproduce the problem -- the customer uses an old iPhone model that I don't have access to, and I've had no luck reproducing it with the same iOS version in the simulator. However I made an update that I have good reasons to believe will fix it (I undid the small changes to the rendering code that were in the last update and did an alternative implementation that completely bypasses the issue, if my guess of what the issue is about is correct). But I obviously don't have 100% confidence that it will fix the bug since I can't repro it.
So I've submitted the update to iTunesConnect and have asked the user to wait until Apple has approved it. If it turns out that the change doesn't fix this issue, it would all be such a waste for the customer (who will have waited for nothing), for all my other users (who will see an update for nothing) and for Apple (who will have reviewed an update for nothing).
This is what ad-hoc deployment is for - testing. You can manually deploy a build to the customer (you need to know his devices UDID) or you can use a service like TestFlight (free) which helps to automate and manage the ad-hoc process.