I am developping my first application on iOS. I am on this language since few days and I am going to share this application in Apple Store ASAP. But I have a big question around architecture.
Currently, I have with about 40 different type of Views, others components and a lot of PNG (30x30). I know that I can reduce considerably the number of Views through the development of a small framework but as it's my first learning-by-practice application, I wanted to move on quickly about all standards components and to start this development without architecture, reusables class or design pattern ... without think too hard.
To be short, I am wondering about the real size of applications in production and the performances. Have we got some constraints with:
Apple Store (upload apps)
Ram Capacity of iPhone during using
Download application from apple store for the user
etc...
Basicly, is it acceptable to have with about 40 screens for an iPhone Application?
Best regards.
There is a limit of 50 MB for over-the-air downloads.
Number of screens is probably not going to be a problem. The amount of executable code associated with each screen is probably not going to be significant. The bigger issue is how much PNG data you are going to have embedded in the app. A single 30x30 PNG isn't very big. 40 of them probably won't very big (depending on how well they compress). But if you have dozens of them per screen, or if you have a big hi-res background image for each screen, then the total amount of data could get big.
My advice would be to just start developing everything in the most straightforward way you can. Don't worry about sizes until you have some evidence that it may be a problem. And do a lot of testing on an actual device (don't rely on the Simulator) running whatever the oldest OS version is that you are willing to support.
Related
I am making an app that uses a lot of fairly big image files. I notice it crashes when they all get loaded on my iPhone 3G (128 mb ram), but not when I test it on a 3rd gen iPod (256 mb ram). So I assume there must be some percentage that is allowed for each app to use? My app has about 30 images at about 440k each loaded so 13.2mb. I didn't think that would be too much. They need to be swapped in and out pretty quickly, so releasing the ones not in use from memory doesn't seem like a good idea...
EDIT:
The app swaps images based on the way the phone is being tilted. It's 30 images from a 3D scene, so when you move it, it changes the perspective. It needs to be as smooth as possible.
The answer is: as much as you want, until the OS complains.
There is no such thing as an absolute memory limit, since it wholly depends on the phone's memory, how much the OS and its related services are taking up, and the time of the month (just kidding, but you get the idea).
You should be scaling down these large image files to fit into memory, or even more so, not loading them all at once considering the screen is so small and only so much can be viewed at any one particular time.
While working on an universal binary for iPhone / iPad, I've been asking my self often: Is this really so good? I believe the iPhone and iPod touch devices will simply download the whole package, including all the irrelevant iPad content. Since my app is graphics-heavy, the iPhone and iPod touch users would suffer from about 10 MB of irrelevant graphics. They're just trash and not used on their device. Same for iPad users, who will see something like 6 MB of garbage image data which is never used. Of course, along with all the non-used code for the device.
I wonder if this is really intelligent. If this is really the future: Downloading and installing a lot of trash and then worrying about buying an 8 GB, 16 GB, 32 GB or even 64 GB device just to be able to install more stuff. I already fear lots of the universal apps I have are just trashing my device full with unused files. It makes me feel stupid.
Any apps that aren't graphic heavy are worth making a universal binary for. eg: if you just have the standard cocoa UI elements and some data. Then all you do is set all the frames relative to the size of the frame.
If its effectively a seperate app (ie: you've got a ton of DIFFERENT picture files for the iPad version, then release it as such. Even if they are just higher-res pictures and such, it doesn't matter.)
You think that's silly? Try re-downloading an entire 80MB app (resources and all!) every time a small code change is made. :)
Given your figures of 8, 16, 32, 64 GB; I assume you're talking about storage capacity, rather than "memory" in the sense of RAM. If this is the case, you may consider compressing your resources and unzipping them to the app's sandbox for easy access on future boot-ups.
Alternatively, you could bundle only the iPhone / iPod resources with the app and download the iPad-specific resources separately. Users might not like the surprise bandwidth usage and it might not even get past Apple.
Finally, you could procedurally generate your resources and your users will love you for the saved space, if not battery life. Perhaps combine the best of both worlds and only generate the resources once?
I have an app which is quite huge. It has tons of images and sounds. In total it's 30 MB in size.
1) Is there an official limit for the app size?
2) Are there other "practical" limits I should consider?
Reading around, there are reports that the absolute maximum size for an application is 2GB (http://discussions.apple.com/thread.jspa?threadID=1605342).
Other than that, if your app is over 10MB, users will only be able to download it over a wifi connection, having the impact that users won't be able to download your application easily when they are out and about.
This might sound obvious, but there are two size limits to keep in mind here - neither are absolutely defined.
One is the limit for the application bundle. I don't know if there is a real limit (other than the device's flash storage limit), but this should rarely be an issue. Keep in mind the 10Mb threshold that the other Phil mentions though. There may be something in the 2GB limit too, I don't know.
The more important limit is on the size of the loaded binary image and it's runtime memory usage. The iPhone is obviously a constrained device in this area. The original iPhones and iPod touches had 128Mb of total RAM, with no paging. Current models have 256Mb, but it's a bit early to limit yourself to that subset of the installed base if you can help it.
Assuming 128Mb, of that a fair chunk is used by the system itself and its background tasks (and people want user background tasks too!?!).
In a conversation with an Apple Engineer he said that apps should be written to use no more than about 25-30Mb! Up to 60Mb may be available but cannot be counted on (but you could use this extra for caching stuff that you can purge as necessary).
1) I believe that you shouldn't ask for maximum size, as you have to aim for minimum possible size for your apps. As iPhone has limited memory (both storage & RAM), you should not create a huge app. (I doubt an app > 200MB can pass through Apple's app check.)
Yeah, Phil is right, when you app is over 10MB, it can only be downloaded via wifi or iTunes. Quite a lot users may want to download anywhere they like using 3G networks, so >10MB is not recommended.
Also, take care those users with iPhone 2G. If you produce a >10MB app, it takes them a day to download your app (if they are lucky enough to have no disconnection at the middle of download...)
2) practical limit ... K.I.S.S = Keep It Simple and Small.
That's it. Hope it helps.
Something I've noticed about every iPhone app I've tried is that they all have places where they seem very slow and unresponsive. It's true of the games, the free apps, the pricy, popular, "professional" apps, and even a couple of Apple's built-in apps. They all seem to have places where they take many seconds or even a minute to respond to screen touches; bog down and show a spinning beachball for seconds at a time; "queue up" input so that a button press appears to ignored only to actually do something ten seconds later like a poorly made DVR; and lock up for so long that the OS watchdog just kills them.
Because these perf issues are so widespread it seems to me that there must be some common performance pitfalls some system gotchas that are coming up over and over again for lots of different people. I'm not an iPhone developer myself, so I'm canvassing the community's opinions:
What are the most common performance mistakes on the iPhone?
Or, what human factors of iPhone development make it too easy to ship with poor performance?
I think that the performance issues are a matter of perception. Apple has employed animation throughout every aspect of the iPhone's interface, which produces the impression of a smooth, responsive device. The slowdowns you refer to appear much worse than they might be because they stand out from the otherwise fluid interface. If you compare the total execution times of these tasks to similar applications on other mobile devices, I'd guess that the iPhone implementations would still come out near the top.
There's always room for improvement, though, and I'd expect that many of the tricks people have learned in the last year will lead to faster, more responsive applications. Even the development tools themselves are advancing, and that should make it easier to diagnose and deal with performance bottleneck. I know I keep learning new tricks every week for squeezing a little more out of the CPU, GPU, or onboard memory.
I'm still surprised by how quickly people have shifted their expectations as to what handheld devices can do. I'm the author of an open source application called Molecules, which does 3-D molecular modeling on the iPhone. A little over ten years ago, these types of renderings were being done on dedicated SGI Irix workstations. A few weeks after the launch of the App Store, I started receiving emails from people complaining that the application was a little jerky when they tried to manipulate molecules with over 20,000 atoms in their structure. In a very short time, people went from treating these devices like phones and music players to viewing them as portable computers.
Memory management is a bit of a beast.
But I think the biggest problem is this: How long can you afford to polish a product that will sell for 99 cents and compete with tens of thousands of other apps and has unknown revenue potential in a rapidly changing market?
The iPhone is a GREAT little device, but the competition for mindshare is fierce and expensive.
As mentioned before the ratio of profit/time spent in development would explain it.
More technically, I would say that the lag you see is created on startup when apps are either getting data over network or calling home to check for updates and so on. Additionaly it may be created with initializing application like loading large amounts of data from database/files, loading gui components and images, drawing and so on.
Similar to memory management this all can be solved by designing operations to run in background, lazy loading and so on but that requires more time, time is money, you don't get much for 99C app which may or may not sell at all.
It is interesting that so many times it is pointed out in professional articles (no ref...) that we should not care anymore about memory and speed because desktops are getting faster with more memory. What people tend to forget is that at the same we're trying to squeeze more power from smaller and smaller devices that are running with smaller resources.
Most web pages for example are nowadays designed to load huge amounts of animations and images and, unlike some, are not tweaked at all for performance but do just okay on desktops. Those web pages have no chance of loading on mobile device. The same goes for applications, designing a fat big framework (or gui widget library) for desktop will make it ultra difficult to port the functionality to sleek mobile device be it iphone, some fruit berry and what not.
As in other things in life, you get what you paid for.
My 99C.
I think the biggest issue is that it's impossible to determine the speed of an app without actually running it on the device. Developers perform most of the basic app testing in the iPhone Simulator (which can run up to 1000x times as fast in my experience). Some operations that take a split second in the simulator might require a progress indicator on the phone, and by the time you realize, it would require a lot of effort to go back and add (and in some cases thread) the operation in question. As Noshredna pointed out, it's generally a 99c app.
The iPhone's processor is also just fundamentally limiting. I've seen several nice looking apps that try to do very impressive things without accepting the constraints of the platform.
This is sort of a side note, and I don't want to start the mobile platform wars, but I've found that iPhone Apps are generally more responsive than Android apps...
Well, because maybe you deleated the app and install again because something wrong happens to it, so it must took awhile, it took me about 2 or 3 days to get full loaded so be patient, it will come eventually. Also maybe your iphone doesn't have any more spaces for your app, or your app is quite heavy, try and delete other apps so it will have rooms.
I'm wondering what's a reasonable size for iPhone Apps. Right now I'm working on an iPhone game, and of course it loads fast into my device since I'm connected directly to it through a USB cable, but I've no idea how long it would actually take to download from the App Store.
In my case it's about 2mb in size, which is reasonable for a desktop or even a flash game, but I've no idea if this is reasonable size for the iPhone.
My other concern is what's the non-wifi download limit of the App Store? Occasionally there are Apps that won't download unless you've got a wifi connection. And personally I've never downloaded such apps, since it gives me a bad impression. So I'd definitely want to stay below that limit.
Also since I'm already asking about app sizes, it would be probably be useful to collect good sizes for other types of apps as well.
Thanks!
Looking through some of the games i have on my phone they weigh in around 7 or 8 mb a pop. I think your 2mb will be fine.
One thing i can tell you for sure is that if you want to be distributable over the cell network your application has to be under 50 mb. If you exceed this it will have to be downloaded using wifi or itunes on a computer.
The 3g network is fast. I wouldn't limit your development based on this - do exactly what you need to do to make your game as good as it can be, and people will download it even if it takes a tiny bit longer. I've downloaded 10MB+ applications from the store over 3g and it might as well be a slow wi-fi connection, it's just that fast.
Also remember that many people purchase on their computers (hence a fast connection) and then just sync to the iPhone, especially those that are in areas with slower cellular networks.
Bottom line, size won't affect downloads, ratings will.
Besides the resonable numbers being somewhat lower the limits:
Maximum app size ist 2GB
Application larger than 20MB won't be downloadable over a cellular connection
I would try and keep it as small as possible. The app-store could probably support, say, a 100MB application, but it wont be nice to install for users.
The problem is installing via the phone - all you get is a simple progress bar, and most people have their phone auto-lock after 1 minute.. So, ideally the app would download in under a minute on an average connection..