A few notes on HeyTell 2.3 for iOS!

We've got a few fun changes for HeyTell 2.3, so we thought we'd write a little bit more about 'em!

Alert Tones: We added a new extra that plays alert tones. You can set a global tone for all incoming messages, and can also set unique tones for friends and groups. You can also configure it to play the alert tone when a message comes in while the app is open. While there are a bunch of ring tones to choose from, we encourage you to check out the Dog Whistle ringtone - 50% of our team can hear it, and 50% can't - can you?

A new Voice Changer option: Alien voice allows you to speed up or slow down your voice - sound like a chipmunk, munchkin, or slow yourself down. If you've already got the Voice Changer extra, the option will automatically appear for you after upgrade.

Export messages to Twitter: We've had a lot of requests for this - you can now, in addition to posting to Facebook and email, you can post messages you sent to Twitter, SMS, or export a link. Note that messages you export this way are publicly viewable for anyone who has access to the link. To export this way, tap the blue arrow next to the conversation, select the message you want to export, then tap the Actions button and select the type of Online Sharing you want to perform.

New translations: We've added Portuguese, Norwegian, and Italian translations - many, many thanks go out to John André Netland for contributing the Norwegian translation and to Gabriele Ravanetti for assistance on the Italian version!

Bug fixes: You may find a few other bugs resolved - note that we continue to recommend using released and supported operating systems only, but if you do run into issues, definitely drop us an email - and a big thanks to everyone who's contacted us so far, we do appreciate the issue reports!

April Fool Public Relay Weekend!

Thanks for trying out the public relay - what a great time! We had over 150 people join the relay over the weekend - some participating, some just listening in. Topics of discussion included mobile technology, accessibility, snake breeding, and oh-so-many things. Messages sometimes flew so furiously that our phones couldn't keep up!

We got a lot of good feedback, and we're going to go back and figure out how to make group chat even better. We've learned a lot and discovered a lot of issues -- and we think we have good ideas on how to improve them while keeping the spontaneous nature of public chat alive. It's too much fun not to!

But if you need your HeyTell group chat fix, there's hope on the horizon. In the next month or so we're going to allow users (iOS & Android!) who have the Groups extra to create Shared Groups, which allow group members to "Reply All." Stay tuned!

Make a Tap-To-Talk Link for HeyTell on iPhone

Did you know that you can create a link that lets others connect to you on HeyTell? You'll need an iOS device and a Facebook account and can put this link in web pages, emails, Twitter...wherever you want others to chat with you - iOS and Android users can connect to you by tapping this link on their mobile devices.

Here are the steps:

1. Go to the Profile tab on HeyTell and connect to your Facebook account.
2. Find your Facebook ID. This is the tricky part, and you'll have to log into the Facebook web page to do this. Go to your profile and mouse-over your profile picture, then look at the status bar for a URL with a number at the end. The format should be something like "id=123456789". We are interested in just the digits; this is your Facebook UID. (More detailed instructions here)
3. Your tap-to-talk link will have the format:

http://heytell.com/user/?fb=#####

Replace ##### with your numeric Facebook UID. (EDIT: You can also view the link by going to the HeyTell Application on Facebook)

You can paste this link wherever you want, and as long as you have your Privacy Level set to Low, others can chat with you just by tapping the link on their mobile device!

This is an experimental feature, so please let us know how it works out! We'll be adding more (and easier, and for Android!) ways to connect in the future!

More HeyTell Server Upgrades

We've been working hard upgrading our servers to handle all of our new users -- and the majority of the work is complete. We think the new system is a lot snappier and more reliable, and we're going to post the following graphs to keep ourselves honest:

This is the uptime for the main HeyTell service, and as you can see there were a few outages over the last few weeks as we worked through a few issues with the upgrade. The high number of outages reported (162) are due to some transient network problems that were reported as multiple outages, and our daily two-minute maintenance period (which is no longer needed).

You can come back here any time and view the graph, which is updated daily.

Please report any problems you encounter to support@heytell.com!

Happy 1st Birthday, HeyTell!

HeyTell just hit its first birthday, and what an incredible first year it's been! On February 10, 2010, fresh off the adrenalin of the Saints' Super Bowl victory in New Orleans, HeyTell was publicly launched with very little fanfare. 33 intrepid users downloaded HeyTell its first day in the App Store.

One year later, with HeyTell exceeding 3.5 million downloads, HeyTell users are proving that there's a place in their hearts (and their work days, and their nights out) for quick, personal push-to-talk style voice messaging.

And for this, we thank you, each and every amazing HeyTell user — you are truly what has propelled HeyTell's growth and acceptance as a vital communication tool for daily use. Your passionate sharing of the app with friends, family, and co-workers makes inroads each and every day in pushing forward the idea of quick voice messaging as a highly effective and personal mode of communication...not to mention minimizing the number of sore fingers and misunderstood text messages out there!

We're also really happy to report that it's possible to bootstrap a product and have millions of people use it in just a year. It's surely not easy; we absolutely owe a debt of gratitude to our family, friends, and advisors, ubiquitous Internet and mobile broadband, cloud-based hosting like Amazon Web Services, and distribution channels like the App Store and Android Market. We believe this entire endeavor would have been nearly impossible to pull off just a few years ago.

So what have we been up to lately? We recently released a brand new backend architecture that should scale to handle our anticipated growth through and beyond the next year and are hard at work on improved clients for iOS and Android. We're also looking towards additional platform support and expanded localization support as part of our efforts to grow internationally. In addition, we hope to have some fun announcements for you in the coming weeks!

And, because no 1st birthday should pass without a 'baby book' of sorts, we give you HeyTell's 12 month usage statistics:

HeyTell reached over 10,000 people by the end of February 2010. HeyTell hit the 1 million user mark in October, 2 million by early December, and 3 million in mid-January. Our biggest download day of 2010 was December 25.

December 25 was also a big day for the iPod 4G - we saw 5 times the number of new iPod registrations on December 25 than any other day of the month!

Registrations don't mean much, though, if people don't keep coming back. Around 450,000 people check in with HeyTell each day now. Each week, 1 million check in. Every month, we see around 2 million users sending, receiving, or checking their HeyTells.

So why do HeyTell users keep coming back? We believe it's because their friends and family keep coming back. Over 1.7 million messages are sent a day in 2011, and, over HeyTell's year of service, over 215 million messages have been sent:

If it were possible to play all audio transmitted via HeyTell end-to-end, it would take 44 years to play it all back!

So who's using what? Our figures show that roughly 25% of our users run Android operating systems, and 75% run iOS.

The Android audience is very diverse, there are 1114 different combinations of Android device and OS, compared to 35 iOS variations. The most popular Android phone among HeyTell users appears to be the HTC Evo; however, the most popular since December 2010 is the Samsung Galaxy S.

So, that's the HeyTell year in review—thanks to everyone who participated in HeyTell's Year One—we couldn't have done it without you! We hope you stick around and we look forward to another fantastic year ahead!

iOS and Android: The Odd Development Couple

We recently ported our app HeyTell from iPhone to Android, and found that we gained a little perspective in the process. Because it uses a large number of system features (native widgets, location, database, audio, network services), porting the app really required a deep understanding of each platform.

A great way to get an understanding of the strengths and weaknesses of any software platform is to port software from one platform to another. For example, in the early days of my programming life, I'd write a simple "Missile Command" game to get a feel for a specific platform.

Here are some of the various perspectives of the iOS and Android platforms, and how we view them differently after the port:

User Interface - iOS has the benefit of being based on a mature UI framework (Cocoa) and Android has had to play catch-up with features (like animated views). iOS has the edge here with some features -- table/list views in particular are much more full-featured, if a bit difficult at times. Interface Builder also is much more slick than anything available on Android (I just edit the XML files directly on Android), so I'd say iOS wins this one.

Application Framework - Android and iPhone have very different ways of looking at the world. Android tries to model an app as a loosely-coupled set of Services, Activities, and Content Providers, while iOS sandboxes each app like a traditional OS. I understand the rationale behind Android's design, but I think it confuses more than it delivers.

Performance - We've never had serious problems with performance, although iOS seems to have a snappier UI in general and do a better job with compositing and animation. Both platforms allow native code (Android via the NDK) for CPU-intensive code.

Language - Objective C does seem to have a steep learning curve and a lot of new concepts compared with Java - especially regarding memory management. However, if you look under the surface, Android has many of the same issues (look up "android memory leaks weak references"). But if you're experienced in Java, you'll have a lot fewer hurdles with things like threading on Android.

Third-Party Libraries - There are roughly equal numbers of iOS and Android libraries on GitHub, for instance. On iOS, you have easy access to any C/C++ library (without going through JNI), while on Android, you have easy access to the thousands of native Java libs. I'd say this one is a tie.

Development Tools - Eclipse is a great environment and is perfectly optimized for Java programming. XCode isn't bad either, and the experience is a bit more polished. I do really appreciate the command-line tools like adb you get on Android, however. My partner is a big fan of the Dalvik Debug Monitor Server (DDMS).

Documentation - Apple has great documentation, and you can find pretty much anything you want to know there or in its example code. The Android docs are not quite as comprehensive, IMHO. We do use Google Code Search to search the Android code base ourselves, which is very helpful at times. But you're going to spend a lot of time on Stack Overflow, no matter what you pick. :)

Market - One feature of the Android Market is that you can push an update at any time without review. This is really comforting from a developer's standpoint (maybe not so much from a user's, but we're happy about it). Android also lets users comment on their stack traces, which is really neat. Okay, sometimes the comments are not so nice, but often they add steps to reproduce - this is really helpful, especially when it seems like we see a new piece of handset hardware appear in our matrix every day and testing across all devices/OSes/firmware revisions/carriers/whizzbang modded ROMs on Android is unfortunately really tricky for a small, bootstrapped team.

Monetization - Because HeyTell is free, we don't have any perspective on pay vs. non-pay apps on either platform, but Apple's In App Purchase capability has served us well. In App purchases are really important for us, because not all users want or need all features, and we don't want to charge users for features they don't want or need. Our fingers are crossed that Google adds an IAP capability soon. In addition, on the advertising side, there really isn't anything on Android quite as turn-key as Apple's iAd. All points go to iOS here, at least for now.

Viral Marketing for Nerds and Data Junkies

Thanks for everyone who attended my Viral Marketing at 360iDev in Austin! Big thanks to John and Nicole for having us as speakers.

For everyone who asked, slides are below :)

Viral marketing by the numbers

View more presentations from Voxilate.

Steve & Jen Speaking at 360|iDev Austin in November

We attended 360|iDev San Jose in Spring of 2010 and had a great time — learned a lot, met a lot of really cool people, and got a chance to connect with fellow travelers on the indie iPhone developer scene. Great fun and a tremendous learning experience!

We enjoyed it so much, that when we heard "November in Austin," we knew we'd be there for sure. It seemed like a good idea to give back and share some of the things we've learned from the release of HeyTell Voice Messenger, so we both submitted talks — and both were accepted!

Steve will be presenting Viral Marketing by the Numbers where he'll bring a developer's perspective to marketing the freemium iPhone app HeyTell Voice Messenger and how it gained 100,000 users using a purely viral marketing model without paid ads or employing conventional PR.

He'll talk about the features and performance of viral vectors by the numbers, predicted vs. actual growth, and will draw some parallels between viral propagation of an app and nuclear reactions. The audience will hopefully take away additional ideas and strategies for successfully incorporating viral elements into their applications.

Jen's going to dig into The Reluctant SysAdmin: Managing the Server-side of a Client/Server iPhone App, where she'll talk about all the fun and not-so-fun things about managing the server-side of a client-server app with an emphasis on security, reliability, and survival (and sleep!) when you're small & indie.

She'll hit on some of the fantastic things about maintaining a server component (metrics, Push Notifications, App Store receipt handling, did we mention metrics?) as well as the not-quite-as-fantastic (24x7 system monitoring, data security, and attacker-thwarting, rolling upgrades for services that can't go down, the occasional sleepless night) and will then focus on processes, products and technologies that make this all easier for a small team to implement, including continuous integration strategies, use & abuse of Amazon Web Services (EC2), and open source solutions for security & monitoring.

As you can see, we're really excited about 360|iDev in Austin - if you're coming, can't wait to see you. If you're considering, hurry up and book it! If you're not, reconsider and book it anyway!

Gauging User Sentiment with Word Clouds

We just released the HeyTell Android Beta and, in the calm before the storm, wanted to take a little break and do something a little frivolous. Perfect time for word cloud creation! Why not take a look at frequency of the words users use to describe HeyTell for iPhone 2.0.3 when reviewing the app on the App Store?

So I popped over to iTunes connect, expanded user comments and saved as HTML. A little command line fu, like such:

grep "review-text" DownloadedComments.html |awk -F '\">|\<\/P' '{print $2}'

Copy and paste the output to http://wordle.net, et voila, user sentiment made pretty:

Requirements Tracking For Total Slobs

I'm now working on an iPhone/mobile startup with just a handful of people, and we typically get things done via shouts, IMs, and emails. This works for us, but I used to work at a company which did things *much* more formally. We will refer to this way of doing things as (drumroll) The Process.

The Process goes as follows: Product Managers generate Functional Requirements which go to the Engineers which turn these into Design Requirements which go to the Developers which develop The Product which goes to QA who uses the Design Requirements to create a Test Plan which then gets sent to Integration Teams which use the Documentation generated from the Design Requirements to make the Installation Guide which then results in the Customer getting ... well, something.

This is a little heavyweight for the standard indie dev shop, but there's a good practice hidden here, which is the generation of Requirements. Why would you want to make actual Requirements when DESIGN.TXT in your home directory will do just fine? There are several reasons:

• They encourage you to record design decisions, and act as high-level code documentation.
• They give you a way to generate test plans - each requirement should be a testable feature of the product.
• When doing a port to another platform, they let you know when you're done (when all the requirements are checked off)
• They let the test team know when they're done (when all the requirements are checked off)

These all boil down to "scoping" your product. Any external party can look at the requirements of your application and get the gist of what's going on without looking at code, and if you do it right, they can test/document/port/translate/regress/whatever and know that they haven't missed anything.

Of course, no one is really going to go through much extra effort generating documentation when they could be making apps and making money. That's foolish. That's why I'm going to show you my bone-simple Requirements Generation Technique. Watch closely!

1. A requirement is defined in a source file (.c, .cpp, .m, .java etc) with a code comment. Here is an example:

// Requirement: When a Butterball is hit with a bullet, split it into two Niblets.

2. Generating a design document is done as follows:

% find . -name '*.[cm]' -print0 | xargs -0 grep Requirement: > design.txt

3. Doing a "Gap Analysis" (comparing two design docs) is done as follows:

% sdiff design1.txt design2.txt

With a little effort, you can pipe requirements to CSV files and upload to Google Docs so other team members can review, make test plans, etc.

Congratulations! You've just replaced thousands of dollars of expensive requirements-tracking tools and at least three middle managers! You've also taken a step to better documenting your code and your product so others can more easily play in your sandbox. You don't need an overweight version of The Process like our example bureaucratic organization, but it helps to have a little organization in whatever you do.