There is not much of a point in posting actual code here, because we're talking about 7 different apps.
All of these apps have been up on the Apple Store and running fine. Until the new iOS 11.1 came out. Now I am being forced to update all of those apps, and rearrange the screen to allow for the new layout of the iPhone X.
Now all of this seems mostly reasonable, if not ridiculous for them changing their own design standard. But the real problem is that I went through all of that. Upgraded Xamarin (Visual Studio), and packages, and Xcode, and the Simulators, AND my Mac system. Everything is up to speed. The apps compile and test fine on any simulator I install them on.
The only change to the code is moving stuff around on the screen. Well, that, and I now need to drop support for anything i386. It all has to be x86_64 now.
From what I can tell, that is a difference from 32-bit to 64-bit. And that change is a dropdown menu choice in the Project Options. In any case, there is no indication at all that there is anything wrong with these apps at all.
So with all of this, I submit my apps for approval, and every single one of them gets rejected because "The app crashes on startup." And they kindly attach a log file showing what went wrong.
Now, I know I can simply scour those logs, for all 7 apps... The log files need to be fed into some other program that can decipher them, because they are not human-readable. Which is just annoying...
What I'm hoping is that someone can save me some trouble and explain what they changed in their systems that is not being caught by the compilers or the simulators.
Any help would be hot.
I am posting my own answer because I have not seen one anywhere that addresses what I have found to have worked. So I am providing this information for the next small developer, like myself, can get some useful answers to questions where Apple and Xamarin are simply NO HELP at all.
Xamarin does provide a page that essentially says, "get your app ready for iOS 11." The most useful part of this is where it shows you how to remove any linkage to anything 32-bit.
Architecture changes
This is mostly helpful. And I thought that once that was done, I'd be all set. There are 2 other things they completely fail to mention:
- You must set your target device to 11.1. You cannot have it set for 9.0. That will make the app crash on an 11.1 system.
- You must make a change in the manual code editing (source) section of the info.plst file. Why this is not done automatically, I cannot say. You must add an entry to the "Required Device Capabilities" section for "arm64". You also must remove the one for arm7.
Failure to do these two things, even after making their suggested changes will cause the app to crash on iOS 11.1 devices.
If you think I'm having a bit of an attitude problem about this, yes, I am. And I will not apologize for it.
It is absurd for Apple to change their design specs, give us very little time to make changes, and then not provide the absolutely essential information to actually make the changes. I blame Xamarin too. For the exact same reasons.
It is also absurd to totally deprecate all the testing devices I have, and then ask, "why don't you test on an actual device?" Because I cannot afford a new $1000 phone for the sake of testing apps that barely make me any money anyway. That's why.
And people wonder why I think it's a pain in the bum to develop for iOS devices.
1) Some of the frameworks that your app use may use libraries, that does not work correctly on iPhone. The reason for that is that when you compile your project on the simulator, is still compile it for a PC architecture, not a mobile one. And if there are any differences, only a real device could tell you about them.
2) I would suggest you to use this method to symbolicate crash reports from Apple. That at least should give you some clue. In summary, what you need to do is after you compile your app, you need to save a few files (.dSYM and .ipa) Then when apple send you back a report, you would be able to symbolicate it into human readable. You can find more info on how to do it here: https://developer.xamarin.com/guides/ios/troubleshooting/questions/symbolicate-ios-crash/
Related
This is one question I am searching for all over the internet, got a lot of results but not for my situation.
As I don't have any apps installed on my device I didn't know how to solve this problem.
What should happen:
- Xcode should install the app for testing camera features I am implementing
What actually happen:
- Xcode fail to install the app saying there is more than three apps installed
As I was about to ask this question, I found somewhere that if I have some apps with the cloud symbol on them like they are in "suspense animation", as I like to call it, you need to delete all apps with this cloud symbol (because you don't use this apps so often they just get partially deleted from your device, meaning you have short storage)
So I am posting this because maybe is the same scenario for a lot of fellows here and could be something to try!
I hope this may help some folks!
Cheers mates!
I have been trying to make the new iOS extension Unwanted Communication Reporting work. Currently I couldn't find any good walk-through tutorial or code-sample to make it work. Above that by just firing up a new project with this extension and building it shows me the option of reporting in the Phone App but not on the Messages app, Moreover, the option to enable it only appears in phone app but it says "sms/phone" so I think this should work for both of them.
I know its in beta right now but just want to know if anyone had any luck with it. Also, There is no code to share as its just the boiler plate that comes with the new project.
This might have been a personal issue. I reset the whole phone and now I can see the options to report message. Apple might have fixed it in their latest iOS build or it might have just been my device issue.
Apple's developer site specifies ”SMS and call spam reporting," which is an app extension that you will have the option of turning on or off.
You may enable an Unwanted Communication extension in the Settings app. I am not sure if Apple will utilize this but i know for android - screen turns red when such spam calls come in, also caller id notes that but currently apple seems to have found a middle ground.
The following worked for me, you can try:
Remove command definition for this in Plist file.
Delete the Target in project (you can delete code folder).
When I start my Debug-Build on an iOS-Device for the first time, a warning from apple is shown which says, that this App would slow down the device and should be re-engenired by the developer (don't know the exact text in english because it's shown in german for me).
In fact I cannot recognize any slow behavior - the app and all the rest works fine and performant. But it's a pity, that new users will be shown this warning on the first start of the App.
Do you have any idea, what the cause may be?
This is answered here, the short answer is use the build hint ios.debug.archs=arm64. The longer answer is that debug builds only build for one platform and we default to 32bit for maximum compatibility.
By setting 64 bit the debug build won't work on older devices and despite Apples hyperbole you won't perceive any performance difference. Notice that release/appstore builds include both versions but take longer to build and are almost double the size.
I've got a very basic, but terribly important and potentially impossible question: how does one go about diagnosing a bug you can't reproduce?
Twice now, I've gotten emails from people asking about app-crashing bugs that I can't reproduce. Non-modified iPhones, current software, tried reinstalling and hard resets, etc. It crashes every time for them, and it works perfectly for me, (not to mention it got approved for the App Store in the first place so I'm clearly not the only one). I had always understood that the consistency of the devices was one of Apple's big selling points for developers, but that also makes it hard to pinpoint what's different about their device from mine...
So, aside from "just keep testing," is there a trick-of-the-trade among programmers for this sort of thing? Some function of the iPhone simulator that lets you test not just different screen sizes but different hardware configurations, etc? Or am I just out of luck, and stuck telling my customer "sorry, it works for me"?
Can anyone share their experiences or suggestions about this?
You should probably start by installing a crash reporting tool like Crashlytics. This may give you the clues you need or at least help you narrow down where to put additional crash logging.
While the iTunes Connect crash reports can be helpful, the crash reporting services like Crittercism are more user-friendly and full-featured. Crittercism has been very helpful in tracking down infrequently-occurring crashes for my apps and can be used no-charge. (I have no association with Crittercism.)
In iTunes Connect you can access crash reports. These crash reports include call stacks that you can symbolicate and then you can see where it actually crashes.
Here is some good instructions for symbolicating: symbolicating-iphone-app-crash-reports
It's important to keep your dsym files from each build & archive safe. You can use them to symbolicate crash reports, to see details of the crash. Users will have to opt in to submitting crash reports though. I think this is a feature of iTunesConnect.
I don't have a iPad, and [bizarrely] creating an iPad app (for the experience mostly) but I would like to put it on the App Store after testing it.
My cousin has an iPad, and possibly could lend it to me. Is there any chance of the iPad being broken by an app that doesn't go outside the App Store rules (no private APIs etc)? I know each app has it's own sandbox, and it can't "get out of it", but has anyone ever experienced a problem that couldn't be resolved by a restore from iTunes, or has anyone had to perform restore at all?
That way madness lies. In essence, lots of things can go wrong - you might drop the iPad into a carelessly placed vat of liquid nitrogen for example.
However, it's incredibly, incredibly unlikely that you'll in some way "break" the iPad by simply installing a provisioning certificate and test app onto it. (I won't say "impossible", as your computer might be struck by lightning, reducing all attached USB devices to a cripsy un-pleasantness the very second you first run the app.)
That said, if you're feeling paranoid, simply get the owner to back-up the iPad within iTunes before you borrow it. :-)