App released for App Store

It took 13 days to get the app released to that Apple App Store this time. I sent them a note yesterday as I was worried about the "review requires additional time" status. From what I could tell on the web this can be a death knell. It appears to mean Apple does not like something and wants to really review it to see if you are breaking any rules.

I sent them a note explaining we just send the data back to our server for it to be processed by the back office staff. Everything is pretty darn tame. I research everything to make sure I am not using a private API, all the graphics are legal, tool bars are in the correct place, back button works like it should, etc. We do store a lot of data on the phone due to CPT, ASA and Diagnosis codes for quick look up later. I wrote my own pop-up menu system that works on both iPhone and iPad to mimic the one I use on the Android but that is just a custom control. I explained all that in my note and it appears to have worked.

I have a couple of guesses. One they might have accidentally put it in the wrong status. I am sure this is easy enough to do especially if you are just choosing from a combobox. Second they could have been worried we were making money with the app by sending claims directly to insurance and they wanted a 30% cut of that. This app is just a simple tool to get data to the back office for processing. It saves the anesthesiologist time and money by not needing to drive back to the office to drop off paperwork.

In the end it is released and ready for our clients. We will be calling them today just in case they don't notice an update is available via the OTA process. I hope to hear some good news from them as I believe I have fixed all known issues at this time.

Previously it was released in a more timely manner: 5 days, 2 days, 2 days and 13 days for this round. Being in release limbo sucks.

Why you don't get crash reports from Apple

I thought our little app was doing great, never a single crash report but then clients said they are crashing it. So what is the deal? Turns out to get a crash report the end user MUST connect their phone to iTunes and OK the submission of crash reports. Our clients are Doctors, they never connect their phone. They use it for scheduling etc. as a smart phone. We will never see a crash report from them.

I looked in the logs and I see they are running iOS 4.1. Yep pretty old but since Apple did not support OTA (over the air just in case you don't know) OS updates they never update their phone. Now 5.0x is not all that great on old phones, they run pretty slow with it, but since many users never attach their phone they never even see good updates and patches. Face it, iOS is fragmented but in a different way than Android.

On the Android side we see crash reports. When the app dies you are given the choice to send the report over your 3G / Wifi / whatever data connection. Our app is based on being connected so sending this data is no big deal. Apple decided to bundle up all the crashes on the phone and horde them like a dragon. 

When I attach an internal beta testers phone to my Mac I get to see all the crashes from our app and all other apps on the device. Stuff crashes a lot from what I see. Those developers never get to see their crashes either. This is a damn shame and a total false sense of security. I pretty much wanted to scream at how annoyed I am at Apple for not giving me access to crash reports so I can make my app better.

I am now going to have to look into some user written crash handlers. You can catch exceptions at a higher level and then you need to try and save the crash somewhere then write it to your server during the next log in. When your app is crashed you can't do much with the data and since there is no central support you are on your own as to how to handle it. We will need a new API on our server to accept the crash data so I can log in and get it at a later time to analyze the situation. They need to fix this. Apple has been less than developer friendly through this whole process and they continue to piss me off.

On the Android side my Motorola Xoom updated to Ice Cream Sandwich and I am happy with the upgrade. The fonts look a lot nicer and I like the new back / home / menu button look. I don't care for the "clear all" vs. "clear individual" notifications from the status bar. 

I wish my phone could be upgraded but they stopped that at Froyo. This is a big downside on the Android side. Each manufacturer gets to decide how much they want to hose over the phone so it is unique to them but when they do that they can skip all future Android releases. As a developer I want the latest stuff. End users don't seem to care and just want it to run. See the iOS stuff above to find out the a lot of iOS users never upgrade. With OTA maybe that will change on the iOS side but the 4.x to 5.x upgrade was not friendly to me or others causing you to lose everything if you did not back it up first. Doing that OTA is not a good idea.

I understand not getting ICS on my phone but I really want Gingerbread as Google sped up various aspects of the UI with some new memory management etc. Guess I will look into rooting it at some point in the future and if it works for me I will do it on my wife's phone too.

Ouch - App Store rejection!

After a full week of waiting to review our app got rejected by the Apple app store. They found a crash, a legitimate and easy to reproduce crash that should have never made it past me or QA. A crash that occurred in all previous versions of the software. A crash that made it through to the store multiple times. It involved turning off some of the editable sections via the admin tool. I was using a tag as an array offset, if all sections are enabled the tag would equal the offset, but in the one test case this was going to cause an index out of bounds. I screwed up and should have labeled the variable as tag instead of as section. I probably was going to do that at one point but the crappy refactoring support in Xcode means I skip doing work like that from time to time.

It is my fault for not catching this earlier. For the test log in we sent to Apple you had three practices to choose from. The bug only occurred on the third practice in the list and only when you pressed the (+) to add a new image to list. Very glad Apple found this issue. I did not want a crash out in the hands of our users and I am sure many would have run into this issue as the layout of the editable items is totally configuration via our administration tool. That tool is not a mobile app but how each client configures what they want the doctor to enter is totally up to them. Annoying this was not caught by QA. As a developer you don't have time to configure piles of test cases in the admin tool then test things out on the mobile side of things. Something like this I should have tested though as it is pretty easy to configure and verify.

It works just fine on the Android. Due to language and GUI component differences the code is not a direct port between the platforms. Could be I was doing a quick conversion to the iPhone or I did the iPhone side first and caught the issue during the Android conversion or the Android code is so different that bug would not occur or I forget to go fix it under iOS post Android conversion. I was back and forth between the two on a daily basis.

Being the sole developer for two platforms is just not easy. I have no one here that can do Objective C code reviews. Someone could look over the Android Java code but I am the only Android developer so some parts of the API would not be familiar too them. Java tends to be Java so I am sure they could find issues if they looked hard enough. Heck, I could find issues if I gave it all a once over. I fixed the issue, ran some tests and we submitted it again.

Within an hour it was back in "In Review" status so Apple obviously saw we got right on the fix and did not move us back to the end of the line. I really did not want our clients to wait another full week for Apple to just start looking at the app again. I am hopeful it gets through the review process in a few hours and we can contact clients starting Monday to let them know a new version is ready that fixes the camera issues and this new issue.

I just got another note from Apple that they need additional review time but they will keep me posted. Must be time for a real test instead of the past two times where it was just shuffled right out into production.

 We don't appear to be getting crash reports from Apple. When we look in the crash report section nothing is listed even though clients reported crashes. I wonder if it is due to them running 4.1 iOS and the tabs for the crash reports start with the 4.2.x series. Does Apple throw away older iOS reports? We could tell clients to upgrade but we list support as 4.0x and above. Plus upgrading to 5.x series is not for the faint of heart. You darn well better back up everything because I know multiple people that had everything blown away. That was not the case when doing 4.0.x -> 4.1.x -> 4.2.x upgrades and people got a false sense of security. A lot of doctors just get the device and never connect it to a computer. I really don't want to walk them through that process.

Here's hoping the new update is available at the store on Monday!