As an iPhone developer I have lately been observing many errors while installing Adhoc builds on my testing/friends iPhones or iPodTouches. Many of them have been really hard to fix and some have just been “nothing but frustrating”.

There was a case where what ever I did, did not work. Many attempts to install using iTunes after trying to change certificates, provisioning profiles have failed. Even the “iPhone Configuration Utility” failed to install the app. I had actually lost all hopes getting it installed on this device. But after a little prayer and just a little hope left, it just worked.

Why did it work? I do not have any answer. Can’t still figure it out. And that was the first time I tried installing an Adhoc build on a device for a Windows user!! Is it really so hard?

Could not install application on device: Error: A signed resource has been added, modified or deleted.

The image that you see here, is another failed attempt at installing an Adhoc build for a Windows user. But this got resolved real quick.

The reason: Mac allows file names to contain some special characters (like ‘*’) which are not valid on a Windows PC. This is one thing you can check if you come across errors of above kind. But not all of them will be the same as above.

If any one else has faced a similar problem and found a definitive solution, let us know here.

Related Posts

• September 21, 2009 -- Apple Announced App Store Resource Center for iPhone App Developers (0)
• August 26, 2009 -- Memory Issues in iPhone OS 3.0 : Sample Code (2)
• August 24, 2009 -- Custom URL schemes and Launching other applications — Best Practices for iPhone OS 3.0 (0)
• March 30, 2010 -- iPhone OS 3.2 GM Seed – Now Available for iPhone Developers (0)
• March 20, 2010 -- Apple Now Accepting iPad Apps (2)

As mentioned in a previous article by Rama Krishna the memory issues in iPhone OS 3.0 relating to UIImageView can be reproduced easily. And here is such a re-production. You can download the iPhone sample application and see for yourself what the problem is. Just open the project, build it for the device (not the simulator) and run it with Instruments (ObjectAlloc) to see a nice little upwards running ramp developing on screen.

Oh!! but remember to run the app on iPhone OS 3.0 and not on iPhone OS 3.1 (the bug has apparently been patched for this version)

Related Posts

• August 24, 2009 -- Custom URL schemes and Launching other applications — Best Practices for iPhone OS 3.0 (0)
• November 5, 2009 -- Adhoc installation issues on Windows PC (3)
• September 21, 2009 -- Apple Announced App Store Resource Center for iPhone App Developers (0)
• August 19, 2009 -- Apple at it again!! (3)
• April 7, 2010 -- 5 Predictions About iPhone OS 4 Features (1)

Apple’s release of iPhone OS 3.0 was eagerly awaited by the iPhone developer as well as the user community alike. But since it has been released I haven’t been able to get a good night’s sleep, not because of the cool new features it had using which I could create new exiting applications, but because of the bugs it has in it’s new iPhone OS 3.0.

Ever since Apple has released the new iPhone OS, I have been looking around for a fix to the problem I have seen with UIImageViews. Frantically “Google”ing for a fix, searching Apple iPhone Documentation again and again just to see if I have missed anything in the Release Notes and Change Logs of the iPhone SDK for UIImageView have not yielded any result. My self imposed deadlines to update all my apps for iPhone OS 3.0 have been breached and a resolution was not in sight.

The bug in UIImageView was its memory usage. As long as an image on screen is left alone after being created, nothing happens. But if you have any sinister designs on your mind, of moving/resizing the image on screen memory usage starts increasing. And there is no way you could do anything to bring the memory usage down, even releasing the image view object does not work.

And the most important finding in this issue is that “there are no memory leaks”. All the memory allocated is always being used!! That is what I had to believe, but performance of my applications on iPhone was rapidly falling down with the amount of time spent on it. Clearly indicating to me that there was something odd with the new iPhone OS.

A detailed bug report that I sent to Apple received a reply stating

This is due to a bug in the graphics system that mis-reports how it is allocating memory to ObjectAlloc, which causes it to display memory usage as continuously increasing.
If you attach the Memory Monitor instrument to your sample application, you will find that the Real Memory usage stays constant through out the application’s execution, indicating that while ObjectAlloc believes memory usage is increasing, it really is not.

For a couple of days, I was devastated at receiving that reply. So, no way out for me from this situation? Are all my app users going to give me bad ratings for no fault of mine?

Fortunately, I received another e-mail from Apple Support acknowledging that

this is a known issue, which is currently being investigated by engineering

Obviously someone else has already reported the issue, but the above response is only a “consolation prize” for me and nothing in the equation between me and my application purchasers changed. They are still going to complain that my apps are resource hogging and give them bad ratings.

This issue seems to be fixed in iPhone OS 3.1 and beyond, but the damage is already done!! Will all iPhone/iPodTouch users update their devices promptly?

Hope your applications are not plagued with these problems, and/or you have found an alternative to overcome this problem.

Happy programming!!

Related Posts

• March 15, 2010 -- Good News for App Developers : Multi-Tasking Added to OS 4.0 (0)
• August 26, 2009 -- Memory Issues in iPhone OS 3.0 : Sample Code (2)
• June 1, 2010 -- Will Microsoft Bing really gonna be a default search for iPhone? (0)
• May 27, 2010 -- Steve Ballmer, Microsoft’s CEO rumored to be at Apple’s WWDC 2010 (0)
• April 7, 2010 -- 5 Predictions About iPhone OS 4 Features (1)