Bit of a hardware question here. I am developing iPad applications for a client and am finding that when I send over beta versions for the client to test, he is finding many more crashes on his devices than I am seeing. A lot of these crashes are 'low memory crashes' which I simply am not seeing/able to reproduce.
Am wondering what differences between the 2 devices there may be so that we can work out if it is a hardware issue. Any ideas?
Make sure of the client's configuration/environment matches your environment. Eg: Outlook Exchange Sync, MobileMe sync. In my Contacts application these caused a lot of crashes because of these.
If possible add more logs and get the logs from console of the client device and verify.
Possibly your client has more stuff running at the same time. Or your own app is background-enabled and is getting killed from time to time...
Always test your own code with the Simulator - it has a feature that allows you to simulate low memory warnings.
Related
My app uses BLE (Bluetooth 4) to connect to a physical peripheral.
My users and I have repeatedly encountered a bug where, at some point, the app stops connecting to the peripheral - you can see an indication that the BLE peripheral is discovered and the connection was established, but then few seconds after, the connection is dropped.
Things go back to normal only after restarting the iDevice.
I’ve done a very long work on checking it and researched this issue thoroughly, until I got to the conclusion that this must be a bug in iOS (tested with 7.1, but probably occurs on 8.0 as well).
My tests and findings:
Occurs with every BLE supporting iDevice.
Occurs with both my own BLE peripheral and with other 3rd party BLE products, both known to work perfectly in normal cases.
It can sometimes work well for even 50 launches, but then eventually it’ll fail.
Network & factory settings reset did not help.
Tested and occurred with various applications: ##
My own app.
Clean new Xcode project that’s only scanning for peripherals and trying to connect to the first and only discovered peripheral.
Apple’s BLE example app: Health Thermometer (with relevant modifications since I don’t have this particular peripheral).
3rd party apps, including the generic LightBlue.
Important note: Every one of the options above worked perfectly for a while (multiple launches), at some point suddenly stopped and then worked again after a restart of the device.
The connection procedure seems to fail when trying to discover the peripheral’s services - i.e. it gets discovered and connected normally, but when initiating discovery of services, it stops responding (didDiscoverServices isn't called).
I have of course tried many approaches found online with no luck.
Can anyone shed some light on this problem?
Is it a known issue?
Was it fixed in a recent iOS update?
Is it going to be fixed?
You can imagine the negative affect such an issue has on my users’ experience, as BLE connection is essential to the product.
I'll appreciate your advice and suggestions on how to solve it.
Thanks!
Update:
Apple responded to my tech support request:
Bottom line(s):
They said they had fixed some BLE related bugs in iOS 8 and urging us to test if it still happens in iOS 8.
They said to start with that and if not, try to diagnose the problem with a utility app they provide.
So far for me it didn't happen with iOS 8, but on the other hand I can see posts about other Bluetooth issues, that are not necessarily related but who knows.
Full answer:
I’m responding to your finding that you and your customers find that
after some point of use, iOS BLE fails to maintain a connection. You
indicate that the problem was identified with iOS 7.1. There have been
issue regarding iOS BLE which have been reported and have been fixed
with iOS 8.0. To best determine whether your issue has been addressed,
of course the simplest means would be to install iOS 8 and to see if
the issue can be replicated. However, as you report that you can
replicate the problem on your deivce with iOS 7.1 the first thing
would be to obtain the Bluetooth Server profile, install it to your
deivce, replicate the problem, then obtain a BLE Server log when the
problem occurs. The profile will have the BLE server report additional
logging details which can help to report issues that the server
encounters. We can see if the issue is one which has been reported
previously. Something to consider is that for all new bug report
issues, Core Bluetooth engineering is requesting that all issues be
regressed with the currently shipping version of iOS - that is 8.0.
For customers with iOS 7.x, there will be no more iOS 7 updates - all
software fixes and bug fixes will be with iOS 8. For this reason, only
issues which are reported with iOS 8 will be investigated. You can
obtain the BLE server profile from the Apple Developer bug report web
page https://developer.apple.com/bug-reporting/ios/bluetooth/. The
instructions for installing the profile and capturing the log, are
presented on the web page. If you capture a log with iOS 7.x, you can
send it to me for review. However, this will be somewhat of an
academic exercise - to know if iOS solves the issue, or whether it
persists, we will need to see if the issue occurs under iOS 8.
Something to keep in mind, once you update a device to iOS 8, you will
not be able to restore it to a previous version. I’m happy to
review your results. If however, the problem persists under iOS 8,
it’s best to submit a bug report to get Core Bluetooth engineering’s
attention on this matter. You can submit a bug report using the Apple
Developer bug report web page. - http://bugreport.apple.com
So it looks like the problem is solved with recent iOS update (either 8.0 or 8.1).
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.
I am contemplating developing iOS apps use Delphi XE4 with iOS. In my research I saw MacInCloud, http://www.macincloud.com/features/tools/tools
Does anyone have practical experience with this? Can I hook up my Windows/Delphi/similar development tool to MacInCloud/xCode for cross compiling (to obey licensing terms) and have the app debugged on my iPhone?
Maybe over time it would be beneficial to buy an iMac, but if I could start creating apps without it would be great.
I recently tried exactly that with MacInCloud. XCode and Delphi XE4's PAServer is now automatically installed by MacInCloud so I had few issues hooking up my Windows and Delphi environment.
What I found was that running and debugging in the iOS simulator on the Mac in the cloud worked fine. However as my upload speed was quite slow a compilation took some considerable time. Each compilation seemed to require an upload of about 17MB for the app and another 50MB for the debug symbols.
There is no way of plugging in your iPhone into the mac in the cloud and MacInCloud therefore recommend that you use a further cloud provider (TestFlightApp.com) to deploy the app to your device. I couldn't test using the TestFlightApp service as I have not signed up for the required developer account with Apple and so cannot deploy to physical devices at all.
All in all, if I was doing serious work I would either buy a Mac or pay for faster upload speeds but despite that I found it an very educational experience.
Good luck with TestFlightApp. That is one of those great services we use to have but not anymore. It use to work at one time but has fallen in great disrepair and been neglected.
Even if that did work, you would go out of you mind if you was working on something that can only run on the device. Not all iOS features work on simulator, like in app purchase for instance.
Where with a real machine at hand it deploys right to device almost as fast as simulator. Just a few seconds longer. Doing it this other way would take 15 minutes or more and require many steps of your interaction. You will forget where you left off in your code by that time.
We have an app in the Apple App Store that we can't seem to get installed on a Verizon iPhone (from the App Store, not Xcode). This may have nothing to do with the fact that it's a Verizon device, but that is the main difference I see between it and the devices I can get to run it.
We are attempting to install the app using a promotional code, but we receive an error when hitting Redeem, as seen in this picture: (promo code blocked out)
ERROR: This code is for an app that is not compatible with this device. You can redeem it on your desktop computer or a compatible device.
The error device is an iPhone 4 (Verizon) running iOS 4.2.8. This error was received when the app was built for 3.x and the assumption was that Verizon devices would not accept apps not built with at least SDK 4.
However, the app was recently updated (yesterday) to use the 4.3 SDK. The app has its deployment target set to iOS 3.1 and has been successfully installed and tested on a device (iPhone 3G AT&T) running this version. This latest version has also been successfully retrieved and tested on an iPhone 4 (AT&T) running 4.3. We were under the impression that every version in-between (3.1 - 4.3) would then be compatible, perhaps this is not the case?
Unfortunately, the Verizon device is not available for Xcode deployment nor ad hoc distribution.
Now for the actual development question:
Is there a build setting that can explain this behavior? Failing that, I would like to determine if the error is limited to the specific device or all devices either running 4.2.8 or Verizon specific hardware.
I would be willing to share a promotional code or two to people running 4.2.8 (or later) on a Verizon device (This is not a bribe. You are welcome to keep the app of course, but I am offering this only for installation testing purposes, not for promotional reasons). If you think you can help, please indicate your interest in the comments. I have not mentioned the app here, because I don't want to unnecessarily spam my product if the answer can be determined without it, but I have no problem sharing that information if required.
Update:
I followed lxt's suggestion and waited to see if it was a caching issue with the App Store servers. Unfortunately, 40 hours after I was informed the update was ready for sale, we are still receiving the same error.
I have found the following threads in the Apple Developer forums confirming this problem is not limited to our app: (A login may be required)
Promo-code redeemer getting "this code is for an app that is not c...
Promo codes broken on Verizon iPhones ?
I have submitted a bug report to Apple (ID 9905790) concerning the issue. At this time, I am unsure if this issue is related to Verizon devices or iOS 4.2.8. Once I receive a definitive answer I will post it. For now, a workaround that appears to be working for others which we have not yet tried, is to redeem and install through iTunes.
Since this appears to only affect Promo Code redemption and NOT store purchases, the issue has lost much of its urgency. However, if anyone is able to provide more information or a solution, it is still very much appreciated.
Update:
I can confirm that redeeming the codes through iTunes and then installing to a Verizon device works fine. This means the problem is not with the app or the build settings, but with the Verizon device App Store redemption.
I have received one reply from Apple in response to my bug report asking me to verify if this occurs on 5.0b5. Unfortunately, as previously mentioned, we do not have developer access to the Verizon device (which is the entire reason for using a promotional code in this instance). I have asked them to confirm if this is a Verizon/iOS specific issue and will update this issue when I have more information.
According to the Apple documentation, it's just a matter of setting the deployment target:
You have indicated that your binary requires iOS 4.3 or later. Apps that require iOS 4.3 or later will not be available to Verizon iPhone users. If your app could be compatible with earlier iOS versions, you may want to reject your binary and upload a new one that indicates the earliest compatible iOS.
That's the message that's normally appended to App Store emails when you have an app waiting for review.
So in theory it should 'just work'.
However, what would be interesting to know would be:
Did you produce the promotional code before updating the app?
If so, do you get the same results with a promo code generated after updating the app (you never know with the App Store / iTunes Connect...)
After 24 hours are you still seeing the same issue? (24 hours being the normal App Store 'refresh period')
Sorry, I could not provide you with more concrete answers. At times it does feel like the App Store is held together with string, so it wouldn't be completely surprising if it was some value being kept around that should have been knocked back when you updated the app.
That said, it's a little strange that your app wouldn't work on the Verizon phone when you built it for 3.x. Why is the Verizon device not available for Xcode deployment? Is it because you don't have one to hand (understandable), or is it something else? There's no reason why it shouldn't be able to have ad-hocs thrown on it.
This is pure speculation:
Since there's a different build of iOS for the Verizon phone, maybe under the hood all apps on the appstore are available twice - one time signed for use on the AT&T version of iOS and one time signed for the Verizon version. The Appstore would deliver the appropriate version depending on your device.
If this would be the case and since redemption codes existed before the Verizon line of phones, it may be that redemption codes point to one version of the app only, leading the appstore to believe it is incompatible when redeemed on the "wrong" phone.
End of speculation.
I'd suggest instructing your friend to buy the app (if it's not too costly) and paying him the money back. If this works, then cleary what we're dealing with is a bug in Apples gift code system and you should be filing a bug report about this.
Btw: you're not alone with this problem. Although they didn't resolve it, the guys on this forum mention the exact same situation.