I have an app that syncs data between devices. Its critical that we know the device that the user is using at all times so we can sync properly. we have implemented OpenUDID but are noticing some odd issues in some of the test users getting new openUDID's when they are installing and running a new version.
Some of the test team is on ios5 and some ios6 and we are trying to narrow down the conditions that cause a new openUDID to be generated.
Out loud thinking - could it be any of these scenarios.
On install of a new app (version of our app) would ios5 or 6 make a diff here?
Using testflight for it to install the new version for us. does that flow cause a new oUDID
Other apps on the phone while we update the version?
Hard reboots of the phone (Power + home) for 15 seconds
App crash, uninstall then reinstall
Any help in advance would be awesome!
OpenUDID uses the UIPasteboard method to store a unique value but there are some limitations. It should not reset when the phone is powered off and restarted but I would think there is a good chance the install of iOS6 resets the pasteboard storage.
If you are able to find a user who consistently does not have the same value even when they are not updating to a new OS version there could be the unlikely situation where another app is messing with the value or if iOS6 is more likely to reset or expire the UIPasteboard.
You could consider making your own code to save to the pasteboard. The benefit of OpenUDID is that other networks can share the same ID for cross app tracking so if you don't plan on using it for that purpose you may consider implementing your own solution. I assume it isn't possible to target iOS6 only but if you could then you could use their new Organization Unique Identifier which would probably be far more reliable.
Related
I think this is not required, at my personal experience only new iOS specific features in my application will require a new release, but a personal client is asking me to confirm this.
With every new XCode release, do I have to rebuild and publish my application in order to make it available at the AppStore of new iOS Release?
If there is any official documentation that proves this will be appreciated!
You do not need to re-publish. Apps remain in the App Store until the developer pulls it (or very rarely, Apple pulls it due to policy violations).
There is likely not any documentation that explicitly states this, but consider a scenario where somebody gets the new iPhone 13 and opts to restore it from iCloud. Data is pulled from iCloud, but apps are restored by re-installing them from the App Store. If apps disappeared from the App Store because they haven't been re-compiled, then anybody who upgraded their phone would discover that a large number of their apps had disappeared.
Anecdotally, my company has apps in the App Store that haven't seen a new submission in over 2 years (since iOS 12). Those apps are still in the store.
You can test your iOS app using the new Xcode 13 and if you got some bug using the new iOS SDK, you can fix it and submit a new version to App Store using the new Xcode.
Its prudent to test your apps on each new OS (preferably before the public release) but in most cases no new release is necessary. Over time you may want to update your app to take advantage of new features or to better support new devices. No app will never last forever but you will likely be able to go some time before having to update.
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).
Before Swift 2.2 the UUID value was the same every time I opened the app, now changes at every opening
I use this code:
UIDevice.currentDevice().identifierForVendor!.UUIDString
How can I do now to identify the user?
Every time you delete the app, the UUID may change.
If you just close and open the app, it's should be the same.
But if you delete the app (or install it again via xcode), it might change.
There are a couple of answers that explain why the UUID is resetting. There's one that offers a potential work around, but I'd consider it far from ideal. But I want to highlight something important about the way UUID's work that serves as a great workaround that has absolutely zero impact on the production OR debug version of your code base or compiled binary.
The value in this property remains the same while the app (or another app from the same vendor) is installed on the iOS device. The value changes when the user deletes all of that vendor’s apps from the device and subsequently reinstalls one or more of them.
All you have to do to prevent this value from changing while developing App-A is to simply install App-B from the same vendor (yourself) and keep it installed during the life time of App-A's development. This is literally as simple as starting a blank new iOS project and install the blank slate to your test device (using the same developer account & such), and then never uninstall it again during development.
App-B keeps a constant UUID for the vendor (yourself) so no matter how many times you delete and reinstall App-A, it will always keep the same UUID.
This actually seems to be a bug IMO. Everytime I run my app in the simulator it generates a new Vendor ID. You can probably get round it by storing the ID into NSUserDefaults on the first bootup then retrieving / comparing the value from NSUserDefaults instead of getting it from identifierForVendor. This will save a static vendor id in defaults but in theory the vendor id will still be changing every boot up.
Kind Regards,
Krivvenz.
Update: I can confirm I have installed multiple apps on the same simulator too but the vendor ID is still changing on every boot.
Update 2: - I have logged this as a bug with Apple - 26195931.
The value of this property is the same for apps that come from the
same vendor running on the same device. A different value is returned
for apps on the same device that come from different vendors, and for
apps on different devices regardless of vendor.
The value in this property remains the same while the app (or another
app from the same vendor) is installed on the iOS device. The value
changes when the user deletes all of that vendor’s apps from the
device and subsequently reinstalls one or more of them. The value can
also change when installing test builds using Xcode or when installing
an app on a device using ad-hoc distribution. Therefore, if your app
stores the value of this property anywhere, you should gracefully
handle situations where the identifier changes.
Refer this link for more info.
I have hundreds of people using my app, but a handful are reporting that the app does not make it past the black launch screen (it immediately closes, before entering into my app). I'm using Crittercism but it's not even getting far enough to catch any exception, which makes it sound like a springboard / backboard problem.
Here's what I've asked the users to do:
Reinstall the app
Delete some apps (to free some space)
Restart the device
None of the above worked. I'm completely at a loss as to what's wrong. The app is in the AppStore and works fine for most users. Furthermore, I can't find anything unique about these users (they're using recent versions of iOS with fairly modern hardware).
Crittercism doesn't show anything, because after the crash - log will be send only at the next launch, so if user doesn't open your app anymore (or can't do it, because he has constant crash).
I advice your to try next ideas:
Do use use keychain or store smth there? It's not cleared after uninstall
Maybe your data is backed up in icloud
Did it begin with the new iOs version (9.0 for example)
Maybe it's some cache problem after installing one version on another,
Can it be the problem of different timezones
Can it be a crash with local settings
If you have feedback with users with crash - contact them and ask about device, iOs version and other
your have crash sections in your itunesconnect profile, maybe there you'll get some information
An update of my app has just been approved by Apple and users are now complaining the app does not launch anymore. It also happens to some new users.
I have absolutely no idea where the problem is nor can I reproduce the problem. I have tested the update on various devices (& simulator) before submitting the update: iPhone 2G running 3.1.3, iPod Touch 2G running 4.3 , iPhone 3G and iPhone 4 running 4.3.1. They ALL work as expected. The update has a few new features like random picking photos from user's photo library using AssetsLibrary framework, I have weak-linked the framework to support iOS 3 and the feature does not load until selected by the user so it should not be the problem. After all, the update has been tested and approved by Apple.
I have difficulty collecting crash information from users with the problem, but I know one of them uses iPhone 4 with iOS 4.3.2. A quick google search reveals that iOS 4.3.2 has problems launching third party apps, I suspect my problem has something to do with this but I can not confirm it. I am planning to downgrade my dev iPhone 4 to iOS 4.3.2 to test it.
Does anybody here experienced similar problem? My app's ranking has dropped significantly because of the negative reviews so I need to fix this as soon as possible.
Edit:
There should not be any watch dog problem, I tested the update on the above mentioned devices with and without Xcode/debugger.
Memory management. I can not reproduce the problem (I tried quite hard) so I can not confirm if it's EXC_BAD_ACCESS, I did check reference count and nil released objects (safely release) when applicable, I am absolutely not a pro in memory management so I take it seriously, I checked leaks and allocations with instruments, stress-tested and did memory warning simulations, no problem was found.
I have UIApplicationWillEnterForegroundNotification in -loadview, it's only available after iOS 4.0 so I check if it exists with & operator because I use it.
I do not persist data other than saving facebook connect token and expiry date (NSDate) in NSUserDefaults, since the problem also happens to new users so I think it's something else
We're going to need more info, unfortunately. But just off the top of my head:
Watch dog? What sorts of stuff are you loading when you launch your app? It may be that resources are constrained on the devices having this issue and you are doing work that should be done a separate thread, or otherwise delayed until after the app has launched.
EXC_BAD_ACCESS. There could be a race condition going on that is resulting in most people able to launch OK, but for some it just isn't working because of bad references. I know, you write good code and manage your references like a pro, but sometimes a non-obvious slip-up can creep in.
Are you safely instantiating some types of classes? An example that bit me once was with the MFMailComposeViewController class. Before instantiating you're suppose to call its static method canSendMail. If a user hasn't setup any mail accounts on their device (hard to figure there would be anyone that fits this scenario, but hey! found out after an update that there are quite a few!) then the app would crash.
What data persistence (if any) do you have? Are you using Core Data? Serialized objects in a plist? NSUserDefaults? Your strategy may be corrupting data you are persisting and that is leading to a crash.