I just met one of the weirdest bug on iOS at my lab.
One of our device (iPod Touch 5th gen, iOS 8.4.1) kept showing a wrong time, despite that the Location Service is on and the Set Automatically in Date & Time is on. The time on that device was always 5 mins late than the correct time.
That seems not to be a big deal but a bit annoying. However, one of our apps for clinic trails is time-sensitive: it always double checks whether the device has the correct time with our server; if the time is wrong, it won't be able to launch at all.
I checked online. It seems this bug has existed for several years! Every time after a system update, some devices will suffer from it. I tried all solutions I found, including restart the device, putting it in Airplane Mode, etc. However, none of them works for me.
Here is the solution I found:
I connected the device with a different network (in my case, from the Wifi at work to the Personal Hotspot on my iPhone), then restart the Set Automatically in Date & Time. BOOM, the time finally got back to accurate EST! After that, even if I reconnected the device back the the Wifi in the lab, the bug doesn't appear anymore and the time stays correct.
No idea what caused this problem, but it is definitely a bug in iOS.
Related
I am facing a very weird issue: my iPhone is restarting.
This issue occurs in a particular scenario only.
Step 1: I have a sync process in which I'm loading data for the whole app. So I'm basically doing a heavy API call by uploading 4-5 camera captured images and syncing the app data;
Step 2: After syncing, I'm pressing the iPhone home button to make the app go in background;
Step 3: I'm locking the iPhone screen(by using side button);
After a few seconds I'm seeing the apple logo and the phone seems to restart. This is not replicating when the app is connected in debug mode. I checked the debug navigator app is using only 125 MB of memory, disk and network values is 0%. Energy Impact is showing high, I'm not sure this is due to high energy impact. I'm facing this issue only on iOS 12.4.
The fact that the phone (or possibly just springboard) restarts, and not just your application means this is Apple's bug. You're not supposed to be able to crash iOS even if you try.
Finding a likely cause will be hard since the system is not behaving the way it's supposed to. The device's logs may have more information from things other than your app. This may be a system API breaking due to any number of actions from your application.
Often with this kind of thing the next OS version will fix it, but if that's not the case or it's important to track down I would try removing ways you're interaction with the system (background APIs, notifications, etc.) and see if anything fixes the issue.
If you find the problem, you may even be doing things the "correct" way according to the documentation and have to find a workaround. If you have the time you can submit a bug to Apple so the underlying issue has a better chance of being fixed.
It seems when your app is in the background and phone locked, Automatic Reference Counting (ARC) closes some connection or deallocates a resource that makes the iPhone restart. Are you closing all connections and removing all references once the upload is complete?
Phones do not spontaneously restart just because of an app’s actions. You’re having an issue with your phone, not with a program. You need to repair or replace the phone.
I am facing extremely slow fetch/network on a RN 0.57 app with wifi (this has been the case since 0.4x, so i think it is version independent)
I am fetching some json or downloading images with RNFS.
It happens on ios.
It happens on dev and release versions both.
It happens both when debugger is on/off.
It does not happen on cellular.
It happens both when using fetch, xmlhttprequest, (RNFS, i don't what that one uses)
It always happens on a wifi connection. (tried several networks/places)
The request takes 10-15seconds on wifi vs sub 1 second on cellular.
While not being sure, the delay partly comes from starting of the request, several seconds pass until i get first event from xmlhttp.
I am stuck and cannot find a way around this.
Issue fixed after moving from ios 11 to 12
I am currently working an iOS app, nothing serious, just a simple budget tracker. The workflow is the following: coding some new stuff into app => connect my iPhone to my mac => building app with Xcode to my iPhone 6 and my wife's iPhone 6 plus (so two different device!). At this point everything works fine.
But after a while (sometimes just a few days, sometimes weeks), the app suddenly stop working on both devices at the same time, without any foreshadow: We don't update iOS and don't do any changing in the environment, the app just start to do like this: https://s3.amazonaws.com/sized-video-assets-public-v1/wp-content/appadvice-v2-media/2015/07/crash_9b28fddfc26f9f0380f1b0d0b2324018-quarter.gif (but in my case, the app can't reach the first view, crashing immediately after start).
The most weird thing is, the crashing issue starts exactly the same time on both different device, but the "no-problem interval" is never the same: sometimes the crash starts after one day, sometimes after two weeks, etc.
After I rebuild the app to devices with Xcode, the whole thing starts over, and the app works fine for a while.
I already tried these things to debug this problem:
Fixing all the warnings cased by the Swift's frequent syntax change, so my app always free of warnings => same problem still there
Checking the diagnostic debug logs on devices, no logs for the time of crashing
Checking memory usage on startup, its about 25MB on login screen (first view), and the max memory usage is about 38-40MB in the app.
Debugging app with Xcode, but as I mentioned above, there is no errors/warnings, and after the successful build, the app works fine again.
What is happening here?
If application is installed with XCode and you don't have a Paid Program Developer Account, the life expectancy of the app is like 48h approximately
(There is no official time of validity for that)
, for a paid program, it's a few month with the correct certificate. Currently it seems to be approx 60 days.
If you didn't sign your app, it has low life expectancy. It's quite new that Apple allow you to deploy for a free account, but it just for testing purpose (other than simulator), if you want more days to test on device, you have to pay for the developer program.
Hope This will help you...
Do let me know if you have any other query.
After noticing people in my company leaving our iPad app open all day on their desks to watch figures progress on a screen, and noticing we have some underutilized HDTVs on walls, I created a tvOS app and was able to put that information on the screen with minimal hassle, and we bought some fourth generation Apple TV units for the TVs. It's a huge hit.
However the one hitch is that the app doesn't stay alive indefinitely. I'm not sure why, but even though we've told tvOS to stay awake and not go to screen saver, every morning I come in and the app has exited and we're staring at the home screen. I have Crashlytics/Fabric installed on the app and I've had it crash a few times and send me emails about it but when I restart the app in the morning I don't get any emails, nor do I see any recurring crashes on their dashboard (it would likely be the same thing every day), so I don't think it's crashing.
So at this point it would make sense that perhaps there's some sort of time limit to how long an app can run that I'm running into.
I guess my first question is am I running into some sort of time limit at all, and the second question would be how could I prevent it from happening?
The intention is for this to only ever be an internal app and not go on the App Store so if there's some sort of way to do this that might get the app rejected by Apple that's not a problem since we're probably never going to release this to the public.
UPDATE:
So while Crashlytics/Fabric isn't telling me that the app crashed, the crash logs in the Devices window in Xcode is telling me that there are crashes.
Specifically it looks like at approximately 11:45PM every night, give or take a minute, it crashes with a EXC_BAD_ACCESS (SIGILL) KERN_PROTECTION_FAILURE message. So I'm left wondering if there's something happening fifteen minutes to midnight in tvOS, or in what my app is doing, or if it's just a grand coincidence that the memory leak or whatever that might be causing this is happening at that time.
I guess one way to test it would be to make an app that does nothing and see if the same thing happens. The lack of answers on this post makes me think this is either an issue in my code (i.e., tvOS isn't enforcing some curfew or something) or that not many people are trying to use tvOS in this way.
We built a game (that's a couple of weeks away from being submitted to Apple) and all this time we've been play testing / debugging on GSM phones (AT&T). One of use got a new iPhone 4 on Verizon. When he's on the 3G network, the game will launch to menu but if the use pushes "Play" nothing happens. However, if he joins a wi-fi network then pushes Play the game starts normally.
Has anyone encountered anything like this? We're fairly certain it's a software issue but have been searching the Internet for any info on what exactly the issue is.
We found out the problem! We changed ports. CDMA (Verizon) doesn't like port 4444, so we changed to another (random) one of 32545 and success! Thanks to everyone and remember kids, CDMA doesn't work on port 4444.
You need to figure out what specifically in your app is causing the game to fail to start. If you are not getting anything logged then there is presumably an error that is not being handled.
Given starting a game requires geolocation, my guess is that on the Verizon phone getting an accurate location fix is taking longer than your app expects and it is silently timing out, or that it is initially returning a location of 0.00000000, 0.00000000 and your app isn't liking that. When on Wifi, location services may be providing an instant initial estimate of location based on the known location of the Wifi network, which would then avoid the issue.
One way to test this would be to hardcode the location or seed an initial location into the app on launch, and see if this fixes the issue.