We've had an app in the app store for roughly a year and are currently on release 4.x. Having upgraded to iOS 13.x a few hundred users are reporting strange issues surrounding logging in to the application and performing simple tasks. These range from app crashing to obtaining subscription receipts to app hanging. The users affected all have varying devices and are running iOS 13.x. These issues didn't appear in iOS 12 so were stumped.
We'd normally triage these issues and release a fix but the problem is that we can't find anything wrong and the other users (remaining 90%) are unaffected by these issues. This leads us to the conclusion that something is inherently wrong with the latest release of iOS.
Has anyone else encountered issues regarding iOS 13 and user access, or noticed an increase in crash rates as a result of iOS 13?
Thanks
Related
I have an iPhone app where I use Firebase Crashlytics.
The following happened:
I build a new version of my app and uploaded it to Testflight.
After that I stopped working for the day :)
The next day I saw a crash report in crashlytics for this new app version, dating to approx. 15 min after my upload the previous day. The data says the crash was recorded on an iPhone 7.
So at this point, this specific app version was only available to me and Apple.
I am sure, that I did not open the app (or experienced a crash) at this time AND I do not even own an iPhone 7.
I highly doubt that Apple Beta-Reviewers are using an iPhone 7 to review an app, after all it's 2021. Also a review 15 min after upload seems not very likely.
Does anyone have an explanation for this? Is the crash even real?
Is it possible that crashes are falsely reported to/by Crashlytics? If so, how?
I've never heard of such a thing tbh.
No, Crashlytics can’t generate crash reports when no one has run the app. Someone ran it.
The fact that you just uploaded it for review makes it very likely that Apple did run it. We have a collection of old devices with various iOS versions for testing our apps in real world scenarios, on less capable devices. I would not be at all surprised if Apple does the same thing.
I got an app that is used throughout the day for collecting signatures. The current release is used by my customers without problems for months on a daily basis. But recently, some customers who updated their iPads (iPad 4 Retina in that case) to iOS 9.1 reported that the app is unresponsive when they start to use it after a night of charging the iPad on a Mac. It takes several seconds to respond to a touch in a list with just a few menu items and signing is not possible at all since the touch events are recognized only every few seconds. The app does not crash until the user gets annoyed enough and forces it to close.
The app is usually the only one used on the iPads. It is used heavily during the day and the iPads are not used at all during night (just charged).
I cannot duplicate the issue on my iPads or in the simulator. I don't see any leaks on Instruments or other problems in the debugger.
The app is build for iOS 5.1.1 and newer (so that it can be used on the original iPad). The App Store version is build with Xcode 6, a beta version, which shows the same behavior (at the customer), with Xcode 7.1. I use Core Data for local storage and CocoaAsyncSocket for communication with the server.
Sorry for being so vague, but does anybody have an idea where to look at?
This problem vanished after Apple updated iOS to 9.2.x, but I don't remember the exact version.
During QA testing of one of my iOS apps an issue has been logged when upgrading a device for iOS 8 to iOS 9. Although I have a good idea where the bug is occurring it is quite a difficult situation to test because once a physical device has been upgraded from iOS 8->9 it is not possible to roll back to 8 again to repeat the tests.
Is anyone aware of a way to perform this type of testing without having an illimited number of iPads. It is not possible using the XCode simulator obviously, and the physical device upgrade procedure prevents rolling back to a previous iOS version. Surely Apple must have some sort of provision for people in this situation but I can not find any information.
Any help would be appreciated.
I recently released an app. It passed well through its testing phase with ten or so users running it day to day on a variety of devices. The app is not really intended for iPad but it works.
On release day a small number of users pitched up saying that the app crashed or that the layout on their iPad was weird. All the complainants were using iPhone 5 or better or recent iPads. I have a pretty new iPhone5, and I went out and bought a new iPad mini. Everything tests perfectly.
So here is my question(s):
What is the strategy for debugging a bug I can't see and I can't test, and when I have no error to work from?
Are there known bugs in these newer devices that I need to be looking at?
Ask users that are experiencing the issue and giving you feedback for sending you screenshots. This would help you to narrow issues with weird layout.
Add a crash reporting SDK to your project like HockeyApp or Crashlytics to get the crash logs. Then, when you symbolicate them, you will get the detailed information about which line of your code is crashing the app.
I have an iPhone app that I have developed and tested on my iPhone 4S. The app is released on the market and some users claim that the app is unusable as it crashes on start up.
I have done exactly the same things as the users have to their devices, running the same version of the app on my iPhone 4S and I cannot get it to crash.
I have been to the houses of users and plugged their phones into my computer to get the log read out and when I do, I get errors that I am not getting on my phone and my mac.
I am completely at a loss as to how I start to find the solution to a problem like this. Does anyone have even the faintest ideas?
A good start will be to integrate a crash log collecting, crash reporting SDK in your app like HockeyApp, TestFlight, Crittercism or QuincyKit.
This will send you the crash logs to you so you don't have to collect them manually. These tools can also automatically symbolicate the crash logs for you so you can find the source of the crash in your code.
You should test a release build before you ship it. Archive a release build and distribute it as an Ad-Hoc build. You can load a saved IPA file to your iDevice using iTunes or Organizer. The thing is that you can test a release build which is the same you would ship to the App Store (they are signed differently but the build configuration is the same unless you changed that).
iPhone 5S ships with 64-bit A7 processor. Your iPhone 4 is a 32-bit device. Most likely processor architecture is not the case but as Apple says: Before you distribute your app, you must test it on actual hardware. Some of the runtime changes can be detected only when the app is running on a device. I recommend you updating your set of test devices with different models. I still own an old iPhone 3GS which is great for spotting performance issues.
The general comments others have posted are correct. Add crash logging into your app with a pre-made SDK and test on an actual device. I can't add much more to those points, but I will tell a short story about a similar bug that I found in one of my apps in the hopes it helps you with your issue.
Our app was predominately iPad2 users. When the iPad4 was released, waves of our users upgraded and they started experiencing an issue that was not present on iPad2. Two network requests were fired off at the same time and the result from one of them was crashing. We eventually found out it was a concurrency bug. The result of the first request was being processed "too quickly" and the code was getting to a critical section of code that was not thread-safe with the other request handler.
While this bug was still possible on the iPad2 if the network latency fluctuated just right, it never happened that way. The iPad4 made it happen almost every time.
You can use https://github.com/CocoaLumberjack/CocoaLumberjack lib to collect crash data logs from users.
Have you considered installing a crash logger in your app? There are plenty out there (Flurry, TestFlight, Crittercism, Hockey App, etc).
Most are fairly straightforward to install - add a framework and a couple of lines of code. Once you've done this, you'll (hopefully) be able to see exactly where your app is crashing on the users' devices, without having physical access to them.