UPDATE, Jun 2013: Apple finally made it possible to easily transfer apps between accounts. Just go to the app in iTunes Connect and choose “Transfer App”.
The short version: It’s not possible.
The backstory: In July of 2012 I started my current job at KURIER.at after they aquired the services of a company I used to work for. Among them film.at, one of Austria’s biggest movie platforms, for which I built the iOS app.
Obviously we wanted to transfer all the existing apps to the Apple account of KURIER.at. Reports stated that Apple does not allow this, but I had hope since those where over a year old and our current scenario seemed like a very common one. So I contacted Apple.
[ Continue reading… ]
It is easiest for me to learn about things gradually. If I am interested in a new area I start following various blogs and people on Twitter who are engaged in that field. My usual approach is to follow every resource that I can discover. I always have the option to delete them from my feeds if they proove to be of no interest to me.
However, it is not always easy to discover these resources and I am always happy to find a good starting point. So I decided to share the resources that I find helpful for various fields. These links might seem obvious to people already interested in these areas, but I do hope that they will be helpful for someone new to the game.
Free free to leave suggestions in the comments if you think that I missed something important.
[ Continue reading… ]
Every iOS user knows this: Apps crash. These crashes are usually the developer’s fault and some are pretty nasty and hard to track down in a development environment. Therefore, it is very useful to collect crash reports from apps that are in production.
Fortunately, there are tools out there that do exactly that. My weapon of choice is Crashlytics. Other options are Hockey and plcrashreporter.
The way Crashlytics works is that an OS X app has to be installed and has to run in the background every time a build of an app is made in order to upload its information, like the .dSYM file, to their service. Xcode connects to the Crashlytics app through a run script. The whole setup process is done quickly and the Crashlytics app provides a very good guide. I do not like the fact that a dedicated app has to run in the background but in the end it is convenient.
Crashes are visible through an online dashboard that shows every piece of information that one might expect: Number of crashes, affected app versions, stack traces, and detailed information about the devices (e.g. iOS version, free RAM, jailbroken). E-mail notifications and integration into other services like Jira are also possible.
I have been using Crashlytics for a few months now and it has proven itself to be very useful. It collected various crash reports that I never saw during the development phase.
The service is currently free but they will announce a pricing model in the near future and I will be happy to pay. Every serious developer should collect crash reports to ensure the quality of their shipped apps.
Backups are important and should obvioulsy not be stored on the same server. Sending a dump of my PostgreSQL database per e-mail once a day seemed like an easy and viable solution – as long as it does not get too big. Gmail accounts provide more than enough space for storing small backups which is why I set up an additional account in order to not pollute my main inbox.
This is the small script I wrote to do so:
#!/bin/bash
EMAIL="db_bak_account@gmail.com"
DATABASE="my_database"
DATE=$(date +"%Y-%m-%d")
FILE="/tmp/pg_dump_$DATABASE_$DATE.sql.gz"
pg_dump --inserts $DATABASE | gzip > $FILE
mutt -s "PG Dump $DATABASE $DATE" -a $FILE -- $EMAIL < /dev/null
You might have to install and configure mutt to be able to send e-mails with attachements. This tutorial shows how to do that.
Store the file somewhere, execute chmod +x pg_bak.sh and schedule the script as a cronjob via crontab -e.
# m h dom mon dow command
0 4 * * * /path/to/script/pg_bak.sh
Now a backup of your database should be sent to the provided e-mail-address every day.
Build-Measure-Learn. While this concept is definitely not new, even though the Lean Startup movement seems to claim so, it is still very important. Unfortunately, there are not too many options when it comes to measuring the usage of mobile apps.
An obvious solution would be to run your own service, something that I have been doing for years. Every API call was logged with a few extra parameters about the user. I also built a small tool to crunch the numbers. If somebody needed more detailed or specific statistics, I had to query the database directly. Another downside to this approach is that hosting this kind of service could eventually become costly depending on the amount of users.
So, I wanted to switch to a third party solution that handles big amounts of data easily and provides better analysis tools. The only three options that seemed reasonable at the time (July 2012) were Mixpanel, Flurry, and Google Analytics.
Other developers on Twitter seemed generally happy with Mixpanel but a look at their pricing table made me gulp. While I personally don’t mind paying for services, it seemed unreasonable to try to convince people at my company to spend a few $1,000 every year just for mobile statistics.
I registered a free account for Flurry and integrated their SDK into my app. Everything looked perfectly fine but after one hour of using the app, data points still would not show up in their web interface. It did not seem very realiable and I stopped exploring it.
Google Analytics is probably the most popular solution for tracking websites and also provides many upsides for apps:
- Regular people are used to the analysis tool and probably even use it for their websites. So all of their data is gathered and accessible in one place.
- It has no problem with big amounts of data. Theoretically, every button click could be logged without any complications.
- It’s reliable. I personally have not experienced any downtime or lost data.
- It’s free. (Some people might not feel comfortable handing even more data to Google, so that should be considered.)
Once you start using Google Analytics for mobile apps, it becomes obvious very quickly that the service was not built for that use case. However, you can bend it to your will.
[ Continue reading… ]
