After a bit of frustration with the Android based Google Play, we’ve decided to port our app to Amazon! You can enjoy all the same great features in this version!
Category Archives: iPhone
June 14, 2012 – 2:17 pm
For any potential customers out there wondering which models of phones/tablets other customers have used Migration+ on…here you go!
Apple iPhone 3
Apple iPhone 3gs
Apple iPhone 4
Apple iPhone 4s
Apple iPad 2 (Wifi and GSM)
Apple iPad 3
Apple iPod Touch 4G
Samsung Droid Charge (Android)
Samsung Galaxy Nexus (Android)
Samsung Galaxy S (Android)
Samsung Epic 4G (Android)
Samsung Galaxy S Plus (Android)
Samsung Galaxy S2 (Android)
Samsung Galaxy Note (Android)
Samsung Galaxy Tab (Android)
Samsung Galaxy Fit (Android)
Samsung Galaxy Ace (Android)
Samsung Fascinate (Android)
Samsung Admire (Android)
Samsung Vibrant (Android)
Samsung Intercept (Android)
HTC Evo (Android)
HTC Evo 3D(Android)
HTC Evo 4G (Android)
HTC Desire HD (Android)
HTC Desire (Android)
HTC Desire S (Android)
HTC Ledgend (Android)
HTC Wildfire (Android)
HTC One S (Android)
HTC One X (Android)
HTC Rezound (Android)
HTC Droid Incredible (Android)
HTC Droid Incredible S (Android)
HTC Nexus One (Android)
HTC My Touch 4G (Android)
HTC Thunderbolt (Android)
LG Optimus V (Android)
LG Optimus 3D (Android)
LG Optimus 2X (Android)
LG Phoenix (Android)
LG G2X (Android)
Motorola Droid Raxor Maxx (Android)
Motorola Droid (Android)
Motorola Droid Pro (Android)
Motorola Droid X (Android)
Motorola Droid X2 (Android)
Motorola Droid 3 (Android)
Motorola Droid 4 (Android)
Motorola Droid Bionic (Android)
Atrix 4G (Android)
RIM BlackBerry Bold 9650
BlackBerry Bold 9700
BlackBerry Bold 9930
BlackBerry Bold 9900
BlackBerry Torch 9800
BlackBerry Torch 9850
BlackBerry Torch 9810
BlackBerry Torch 9860
BlackBerry Curve 9370
BlackBerry Curve 9360
BlackBerry Curve 9350
BlackBerry Curve 8520
BlackBerry Storm 2
June 11, 2012 – 2:17 pm
Migration+ has been out since mid-March 2012 and now that we have a pretty nice set of data to look at, we’ve found some interesting trends that we’d like to share.
- At the time of this post we’ve had 3,100 users of Migration+. We’ve had a pretty significant ramp up. We’ve had more users week over week, which is encouraging for us.
- We’ve seen average of ~445 contacts per user. This is many more than I would have expected. I myself only have around 125 contacts in my phone and I consider that a bit excessive. However, it does fall nicely into something called Dunbar’s Number which says that the average human can only have social relationships with 100-230 people (with 150 as a commonly used reference number). So why does our average customer have so many!? We have a few theories on this, but that’s another post. Even crazier than the average, we had a user migrate 8,269 contacts and at the current count we have 58 users that migrated over 1000 contacts in ONE migration!
- OS Distribution:
- ~13.1% of users are migrating contacts FROM Android. Our average user moving FROM Android has 499 contacts.
- ~86.6% of users are migrating contacts FROM iOS. Our average user moving FROM iOS has 434 contacts.
- ~.3% of users are migrating contacts FROM Blackberry (worth noting that we have only recently released a version of Blackberry and it’s limited functionality). Our average user moving FROM Blackberry has 456 contacts.
- Generally speaking the majority of contact transfers are going TO Android.
- We’ve worked on over 60 unique smart phone models. The great news for users is that Migration+ typically works best on the newest models.
- What countries are using our app to migrate contacts? We have a nice map representing country based use posted here. At a high level, the US, Canada, Australia, and Europe are our big users.
We hope to continue sharing interesting information like this with those of you who are interested.
April 17, 2012 – 8:49 am
Yes that’s right, search results for Google Play suck! The apps displayed in results are consistently irrelevant to the topic searched and the search results are most certainly not appropriately ordered to give users relevant results for their search terms. On top of the fact that the search results suck, SEO for Google Play is a black box which makes it even more frustrating.
Since we launched Migration+ in early March on both the Apple App Store and Google Play (formerly Android Market) we’ve spent a bit of time trying to optimize how our app gets found by users. After recently reading a TNW article about Instragram being buried in Google Play results, I decided it may be valuable to detail our efforts in this area to illustrate how challenging it really is for a startup in this space.
In the first version we published on both the App Store and Google Play, we naively published a simple paragraph about our app. For the Apple App Store we put in keywords describing what we wanted the app to be (i.e. move docs, sms, etc.) not what it was at the moment (contacts migration) – newbie mistake. It’s relevant to note that Google Play does not have a specific field for keywords. After publishing we expected that it would take a little while for indexes and search results to show our app, so we stayed patient – roughly a week. After a week and after reading a good existing theory about Google Play’s search algorithm as well as several for the Apple App Store, we adjusted our description to reflect the search queries we thought would be relevant to for users to find Migration. We also adjusted our title slightly and for Apple we adjusted our keywords. Here are a few sample search terms we were targeting:
- move contacts
- migrate contacts
- contact migration
Less than 24 hours after changing the description, keywords, and title we saw Migration+ show up in the top 25 results for many of our search terms in the Apple App Store. However, in Google Play we were only showing up in the top 25 for one search term, “contact migration”. Since then we’ve been tracking search term rankings for Migration+ thinking that more downloads/installs/time in the respective app repositories would increasingly benefit the ranking. That assumption seems to be true on Apple, but not currently true on Google Play. Although we’ve had ~250 downloads over the first few weeks of launch on each OS, our Google Play ranking has not improved in any significant way. Because of the lackluster ranking on Google and the fairly good ranking on Apple we’ve been trying to figure out what’s going on. We’ve noticed two big problems…
Problem 1 – Irrelevant Search Results on Google Play. Take the search term ”move contacts” for example, where we are ranked #4 of the Apple App Store and #316 on Google Play. In the search results on Google Play we’re ranked behind apps like:
- Green wold [Go Contact The
- ES File Explorer
- Luma Live Wallpaper
- Antivirus Free
- PicFolio for Picasa HD
- Gift Shopper Pro
- Shead Spreet Pro
- RadiantWalls HD – PlanetScapes
- ToDo List Task Manager -Lite
- MoneyWise Pro
…and about 200 other apps that are fairly irrelevant to the search term used. Essentially this seems like a case of “downloads are most important, not content”. If an app that has been downloaded many times and has either of the search terms in it’s title or description, it comes before less downloaded apps with more relevant or exact match search terms in the title or description. Here are a couple detailed examples of how irrelevant the results can be:
- If you go to Google Play from your web browser and search for “migrate contacts” on the first page of the results, you’ll find Pocket Agent® by State Farm Insurance. If you look at the description for the app it has nothing to do with contacts, it’s for insurance claims! The app description has no mention of the word “migrate” and there is only one sentence that says “contacts” and it states “Read contacts data – Used by On The Move™ as an optional privacy measure to determine if an incoming text message is from someone in your contact book.” However, this app has been downloaded between 100,000-500,000 times in the last 30 days.
- Currently, our best search term for Google Play is “contact migration” where we rank 12th. If you search Google Play for that search term, the 8th result on the page is Mighty Grocery Shopping List. It’s a nice looking app that has absolutely nothing to do with the Google Play search terms. The description does have the word “migration” in the description but it’s used to describe upgrading from the lite version of their app to the full version. The description also has the word “contact” used in a sentence where they leave their email address so you can contact them. This app has been downloaded between 10,000-50,000 in the past 30 days. Almost all other results on the first page do not even have the word “migration” anywhere in the title or description! However, almost all of them do have a significant amount of downloads in the last 30 days.
Problem 2 – Number of Results on Google Play. This second problem is intertwined with the first problem. If you search the App Store for any of our noted search terms, most of them are low to medium competition (less than 50 results). In fact, only 3 of them are over 50. All of our search terms and essentially every search on Google Play results in what would be considered a “highly competitive” search term (hundreds of results). To get specific, all of our search terms yield at least 250 results on Google Play and most yield 500!
I emailed a few people at Google with polite messages about my concerns in hopes of getting information about their direction on search for Google Play or perhaps a brief explanation of how best developers can work with their search results. Unfortunately, I haven’t got any responses. Before anyone flames, let me freely admit that I am not a professional when it comes to SEO. I should also state plainly that I am typically a happy Google product and service user. I hope this post draws some attention from the right people at Google about how challenging this has become – especially for small developers.
NOTE – there was one other problem we were going to list, lack of exact name match. However, for Migration+ at least, this has seemingly been fixed recently.
March 28, 2012 – 7:44 am
We’re in the midst of finalizing a first build of Migration+ on BlackBerry, which Leo and I are very excited about. This means you’ll be able to migrate:
- Contacts from Blackberry to iPhone
- Contacts from Blackberry to Android
- Contacts from iPhone to Blackberry
- Contacts from Android to Blackberry
- Contacts from Android to iPhone
- Contacts from iPhone to Android
All with a single app, Migration+! As with our iPhone and Android versions of Migration+, you’ll be able to do these contact migrations over wifi if your service is already turned off on one or both phones. If anyone is interested in getting an early release of the app to test it out, let me know!
March 26, 2012 – 11:58 am
For all you first time or aspiring developers, we’re putting together a list of tips to test your iPhone or iPad app so it has less issues and less crashes. This list was created as a result of our ongoing development of Migration+. We realize we are not the end-all-be-all of app testing knowledge, this list is meant to be helpful for app development as of March 2012. It is not intended to be the final word on iPhone app testing.
1. Test it on the iPhone Simulator FIRST
This goes without saying, but before you put your app on a real iPhone, do yourself (and your beta testers) a favor by trying it out using the Apple SDK iOS Simluator. This will help you test on the latest version of iOS and will give you a general idea of if your app works in a simple and controlled environment.
NOTE: if you do not have a MAC (Apple says this is a requirement for running the simulator), there are ways to create a OS X virtual machine on Windows or Linux.
2. Test it on your iPhone(s)
Similar to item #1, if you have an iPhone, you should test on your own phone before distributing a beta version to users. Make sure to try tips 4, 5, 8, 9, and 10 on your iPhone (if possible). This step also means you will complete the prerequisites for being able to distribute your app to other beta users during this step (create a provisioning profile, build the app for distribution, know how to get a device UUID). Rather than recreate the wheel, we suggest using the instructions here from Stack Overflow which describe this in detailed steps.
3. Get beta testers
This may be the hardest or easiest step. You need beta testers with a variety of iPhones running a variety of iOS. If your app is going to be used on iPad, you need a variety of iPad flavors too! Our strategy for this was to ask friends and family to try it out. If your friends and family aren’t the right candidates, then you can appeal to people on a variety of forums (i.e. http://news.ycombinator.com, http://betali.st/, or a variety of other iPhone development forums). If you can’t find free testers or you need people doing testing at a more professional service level you can enlist help from service providers like http://www.prefinery.com/, http://www.utest.com/, or http://www.centercode.com/. If service providers don’t appeal to you, you can potentially find contract/bid based app testers via sites like http://www.freelancer.com, http://www.elance.com, or http://www.vworker.com.
In any case, you need testers that will give you regular feedback on the beta versions as you release them. Target people that you believe will be engaged in the testing…ideally people who are genuinely interested in your app! We also recommend reviewing Joel Spolsky’s article Top Twelve Tips for Running a Beta Test.
4. Make memory problems
Many and more of the problems encountered with apps are related to memory problems. The good news is that it’s fairly easy to simulate high/normal/low memory situations and then run your app to see what happens. The easiest way to create memory use is to open Apple apps (i.e. Safari & Mail) which will still run in the background while other (non-Apple) apps are open. Here are the general rules of thumb we use:
- High memory situation – The idea here is to simulate the “best case scenario” for your app. Your app gets all the love and attention for a few minutes and has most of the system resources available to it. To prep this scenario, ensure notifications are turned off and no other apps are running. Usually done after reboot. 70%+ memory available.
- Normal memory situation – For this scenario you’ll want to simulate how users really use their device. A few things may be open, notifications are on. We typically open 3-5 Safari windows and have notifications on for a few apps.
- Low memory situation – This is the key testing scenario. Turn on notifications (3+ apps). Open 10+ Safari windows and resolve content.
5. Measure memory
Adding code to measure free memory of the iPhone before and after specific events in your app or on intervals can be useful in beta. Though this can be useful for production too, we suggest that you weigh the performance factors of keeping such code in a production release. The topic and a code example are available via Stack Overflow.
6. Make a tutorial (video or screenshot heavy)
Having a tutorial that explains how your app works and ideally showing how it works is something we’ve found helpful for getting testers started. Once they know “how it should work” it should make it easier for them to identify and describe issues.
NOTE: Since iOS allows screenshots, encourage your beta testers to use screenshots to show you any errors during the beta test.
7. Review crash logs
For your phone and any users that are tech savy enough, ask them to give you crash logs any time that a crash is experienced. Crash logs include error information as to why your app crashed. Crash logs are located here:
- MAC: ~/Library/Logs/CrashReporter/MobileDevice/<DEVICE_NAME>
- Windows Vista/7: C:\Users\<USERNAME>\AppData\Roaming\Apple Computer\Logs\CrashReporter\MobileDevice\<DEVICE_NAME>
- Windows XP: C:\Documents and Settings\<USERNAME>\Application Data\Apple computer\Logs\CrashReporter\<DEVICE_NAME>
If there are multiple files in the folder, filter by date. You should have two files per crash time a .CRASH and a .PLIST file. Both can be useful. OK so now you have some crash logs, how do you read them an take action? We are not experts in this area, but we suggest a useful article from Jared Wiltshire called Deciphering iPhone Crash Logs.
8. If your app depends on system resources (i.e. internet connection) test for what happens if those resources are not working properly.
If your app relies on an internet connect as most apps do, you should test to see what happens if you have NO internet connection (i.e. Airplane Mode). Does your app handle it gracefully? What happens if you have an inconsistent or very slow connection (i.e. Edge)? If you can simulate a slow connection at home via wifi, great. Otherwise, find where in town you have bad cell service and spend a bit of time there testing! For other system resources, we encourage the same type of testing. Try to disable the resource then test your app!
9. Ensure your testing on different iOS versions that are “in scope” for your app (4x, 5x, etc.)
This was one we ran into shortly after our first release. Migration+ worked fine on iOS 5.0.1 but had an issue exporting contacts on the new version of iOS (5.1). If you have the means, we suggest getting a couple test phones so that you can personally test new versions of your app on multiple iOS versions. We use multiple test phones but typically keep at least one with the latest available OS and one with the “most prevalent” version.
10. Use special characters and A TON of text
For any text fields in your app, you want to test weird entries! Try all the special characters you can think of and try varying lengths of text. What will happen if someone pastes this entire post into the username field on your app? You get the idea…the general premise here is that if it can be done, users will try it. Worse yet, hackers may try it to compromise your app. Be sure not to skip this step! In our case, we had to worry about a variety of languages because people store their contacts in whatever language they prefer. We also had to be sure we accounted for system length requirements when transferring data between iOS and Android.
As always, we like user feedback. If you have other tips on how to test your iPhone or iPad app successfully before releasing it, please share!