Friday, September 26, 2014
When Should I Drop Support for Android 2.3 and iOS 5?
My previous company, Logos Bible Software (recently renamed to Faithlife Corporation), has just dropped support for Android 2.3 Gingerbread for their suite of mobile apps and will soon be dropping support for iOS 5 for their iOS suite. This caused a few minor complaints on the Android side, but for the most part people understood that their device was too old to be supported. On the iOS side, there are many users still using the original iPad which runs iOS 5 and they are experiencing some crashes due to the iPad 1 not having enough memory to handle the needs of the Logos apps. Obviously the ideal situation is to leave those users with a version of the app that performs well on their device, but at this point is it worth the extra developer hours to fix a problem that only exists for a small percentage of users on a soon-to-be obsolete device? It's a tricky problem.
Thinking about that problem led me to muse on how an app can get to this point in the first place. When should a developer drop support for an older operating system? This applies to desktop software programs as well, but the pace of desktop operating systems changing is so much slower than mobile, I don't think it's as big an issue.
1) You could set a hard and fast rule that you drop support for an operating system version when the percentage of users running that version drops below 5% (or some other arbitrary number).
2) Pick a cut off date and drop support for the operating system version on that date, regardless of how many users remain on that platform.
Thinking about that problem led me to muse on how an app can get to this point in the first place. When should a developer drop support for an older operating system? This applies to desktop software programs as well, but the pace of desktop operating systems changing is so much slower than mobile, I don't think it's as big an issue.
The choices
There are two main approaches I can think of:1) You could set a hard and fast rule that you drop support for an operating system version when the percentage of users running that version drops below 5% (or some other arbitrary number).
2) Pick a cut off date and drop support for the operating system version on that date, regardless of how many users remain on that platform.
Issues with the first approach
If you insist on waiting until the user base drops below some percentage, the main problem is who knows when that will happen? At the time of this writing, Android 2.3 still has over 11% of the total Android marketshare. It could be quite a while longer before it drops below 5%. Additionally, if that's the only criteria, it's easy to see how performance could start to degrade on older devices because if there's one thing you should know about developers, it's this: Developers like having the newest stuff. They run the beta version. They upgrade their devices as soon as they can convince their spouse they "need" a new phone "for work". Developers are testing their code on that top shelf, speed demon device they love, not the $50 bargain bin smartphone your parents picked up to go with their Walmart family plan. Now don't get me wrong, this is the fault of the developers. They should be testing on those devices FIRST, instead of not at all. But that's not fun, and unfortunately, many devs won't do it. So by the time an OS version drops below the magic percentage, the app might be so fragile on that platform that it's unusable anyway.
Issues with the second approach
From a developer's perspective, it feels a bit weird to release a new version of an app that drops support for iOS 5 or Android 2.3 (etc) without any real reason other than "we want to leave those users with a stable version". Granted, that's an admirable goal, but "this new release adds five new features!" and it's not necessarily unstable/unusable, so it feels like you're cheating those users out of the new features and fixes. The instability creeps in over time and is hard to notice until it's already too late. Objectively speaking, this option is probably preferable to the first choice, but when it comes time to actually make that call, it leaves both users and developers unhappy.
Other options?
What else is there? Maybe Apple has the right idea. They say that developers should support the "current version and the current version - 1" (I tried really hard to find a source for this, but had no luck. Pretty sure it was a slide in a WWDC presentation). That probably works on iOS and OS X where most users update to the new version right away (if their hardware supports it), but it's not really feasible on Android or Windows.
I'd be interested in hearing other people's thoughts. I don't know what the right answer is, but it's definitely a tough problem and one that is important to get right to avoid leaving a bad taste in the mouths of users.
Sunday, August 24, 2014
Why you should worry about the size of your Android app
I find that being in this situation makes me pay much closer attention to the size of apps when browsing Google Play. If I'm going to install an app, it needs to provide enough value to be worth taking up space on my phone; the bigger the app, the more value it must provide to me.
Google, in fact, seems to agree with me. They've said on numerous occasions that smaller Android apps (also called "APKs") get installed more and uninstalled less. Consequently, making your app smaller could result in a boost in your Google Play search rankings, and increase your retention rate.
Remove third party libraries
Do you really need that third party library that gives you support for 100 different ViewPager indicator styles? Or could you get away with pulling out the one style you want to use and including it in your project directly? Reducing library dependencies is probably the biggest win you can get when trying to reduce app size.But it might not be easy. It may take some time to pull out the pieces you need, and you may make a mistake or inadvertently introduce some new bugs. High cost & risk, high reward.
Proguard
Proguard shrinks your app size by removing any unused methods and classes. It also makes your app harder to reverse engineer by renaming your methods from something like void sendPasswordToServer(String password) to void a(String b). You can imagine how this also makes your app smaller.
If you're starting a new app, enable Proguard in your build right now. Seriously, go do it. Proguard is super easy to set up for a new app...the more code and libraries you add, the trickier it gets to add Proguard and be sure nothing will break. Five minutes of integration work now could save you major headaches later.
Shrink those images!
Image files take up much more space than text files, so ideally, you won't have many of them in your app. On the other hand, apps that include a lot of visual content are much more pleasant to use than staring at a wall of text. So what can you do?
Enter ImageOptim, a free program for Mac OS X that reduces the size of your images by removing unnecessary metadata and other tricky optimizations. (If you're on Windows, you could try PNGGauntlet, which I've heard works well, but I haven't used myself).
When I receive an image from one of our designers, I always run it through ImageOptim before adding it to an app (Android OR iOS). I frequently see size reductions of over 95%. If you haven't been doing this, try running all your images through the optimizer and you might be surprised at how much space you can save.
Overall, reducing app size helps you, as a developer, get your app installed by more users and it helps your users by being respectful of the limited amount of space they have on their mobile devices. It's really a win-win situation, so it's something that developers should constantly keep in mind.
Monday, April 15, 2013
Robert Saunders: XCode Shortcuts
Just saw this post on Xcode Keyboard shortcuts and found it incredibly helpful!
Robert Saunders: XCode Shortcuts: Some people hate it, but I am a big fan of XCode. Its important to make the most of the space you have, especially when you have limited space.
Robert Saunders: XCode Shortcuts: Some people hate it, but I am a big fan of XCode. Its important to make the most of the space you have, especially when you have limited space.
Tuesday, July 12, 2011
May I Have the Definition Please?
If you use Google's Chrome browser, you may or may not know about the Chrome Web Store. You can access it from the new tab page, and in it you will find a wide variety of apps and extensions for Google Chrome.
Probably the most useful extension I have found so far is the Dictionary Extension by Google. The extension puts a button in your toolbar where you can quickly type words to define. This button however, is not what's exciting about the Dictionary extension. After installing the app, when double clicking any word on any webpage, you'll get a nifty little pop up definition, as seen here:
Many times you will also see a microphone icon that will pronounce the word for you when clicked. Extremely handy.
The Dictionary Extension by Google is the first extension I install when using Chrome on a new computer and I highly recommend trying it out.
The Dictionary Extension by Google is the first extension I install when using Chrome on a new computer and I highly recommend trying it out.
Monday, July 11, 2011
New Domain, Same Old Blog
As you may have noticed, you're now viewing this blog at drewhannay.com rather than drewhannay.blogspot.com. This is thanks to me finally being willing to put down $10 for my own domain name. I figured considering how often I tell people of the importance of owning their online identity, I should probably follow my own advice.
The whole domain buying process was actually incredibly simple. After a quick Google search, I ended up at the Google Apps Sign Up page. You get the option to either set up an existing domain you own with Google Apps or buy a new domain name.
After finding out that my domain name was available (Not many other Drew Hannay's out there, thankfully), I just typed in my Google Checkout password and I was off and running. About five minutes of clicking through wizards and I had my own custom Gmail, Google Calendar, Google Sites, and Google Docs set up with a @drewhannay.com address.
I did run into a bit of trouble setting Blogger to point to my new custom domain (which was the original goal after all...), but a quick search for the error message got things sorted out. Turns out the problem was that by default, Google Sites redirects all your traffic to itself, rather than letting it go to Blogger. One setting change later, everything was working.
I highly recommend snatching up the domain name for your name if it's still available. Even if you're never planning on using it, owning the name will prevent anyone else from buying it and using it for stuff you don't necessarily want to show up when a potential employer googles you.
The whole domain buying process was actually incredibly simple. After a quick Google search, I ended up at the Google Apps Sign Up page. You get the option to either set up an existing domain you own with Google Apps or buy a new domain name.
I did run into a bit of trouble setting Blogger to point to my new custom domain (which was the original goal after all...), but a quick search for the error message got things sorted out. Turns out the problem was that by default, Google Sites redirects all your traffic to itself, rather than letting it go to Blogger. One setting change later, everything was working.
I highly recommend snatching up the domain name for your name if it's still available. Even if you're never planning on using it, owning the name will prevent anyone else from buying it and using it for stuff you don't necessarily want to show up when a potential employer googles you.
Sunday, March 20, 2011
Pi is Wrong
It's a shame people are so opposed to change. Most of trigonometry would be a whole lot easier to understand if we didn't use Pi.
Tuesday, March 15, 2011
Wheaton College Android App
So for all of you members of the Wheaton College community, and for anyone who might be visiting campus, I have a gift. The (Unofficial) Wheaton College Android App.
Student made by yours truly, Andrew Wolfe, and Alisa Maas, this application for Android phones features several useful tools for students, faculty, staff, and those visiting campus for the first time. You can browse the college's intranet (provided you're on campus wifi!) including the popular "Who's Who" area. Daily dining hall menu's are also available for viewing, so students can easily decide whether or not they will make the trek out of their room for a meal. Similarly, students can view the semester's chapel schedule to see upcoming speakers.
A useful feature for visitors unfamiliar with the campus is a interactive map showing the locations of every building and including easy check ins with Foursquare and the ability to see who else is currently checked in at that location.
Rounding out the feature list is a collection of links to those obscure pages on the college website that you frequently need but can never quite figure out where they are. An upcoming revision to the app will let you add and remove your own links to create your own custom list of shortcuts.
So the point here is basically that all of you with Android phones out there should head over to the Android Market and download the Wheaton College Android App. Enjoy!
Subscribe to:
Posts
(
Atom
)