BIT-101 Blog

So my iPhone game, Falling Balls, has been out for almost a year. In the first few weeks it was out, it rose to be the #1 free application on the iTunes App Store. Trust me, this surprised nobody more than it did ME. It stayed in the top spot for a day or two, maybe more, I forget exactly, then started slowly sinking down the chart. But it sank quite slowly. I think it stayed in the top 100 for something like a few months. And even after it was out of the top 100 free apps list, it was still hanging in there in the top 100 free games list. Of course, all good things come to an end, and eventually it went out of site.

Until now! Yesterday, somebody tweeted a link to this review:

http://blog.appboy.com/2010/01/falling-balls-for-iphone-is-everything-a-mobile-game-should-be/

Now you can’t ask for a better review than that. I read it, smiled, got a nice ego boost out of it and got back to work.

Cut to this evening. I get home, I’m relaxing in my chair, my iPhone is sitting there beside me. I get one of those bored moments where I think, maybe I’ll download a fun little iPhone game. I figure, let’s see what free games are available first, maybe I’ll luck out and get something fun for nothing. I open the “Top 25 Free Apps” page, and to my astonishment…

Yes, Falling Balls is the #2 free application! Amazing.

For the past few years, I’ve posted a review of the previous year and a look to the coming year. So, I’ll do it again.

2009 was a very interesting year. Like this year, last year I had a whole bunch of unused vacation time at the end of the year, so took a couple of weeks off over Christmas. I decided to dive into Objective-C and iPhone programming. Little did I know how much that would dominate the next year, both in terms of my personal projects and work projects at Infrared5. One of the very first things I did was a little game called “Falling Balls”. A stupid little thing where you tilt the phone right and left to avoid … well … falling balls. It was just a silly thing I did in about 1.5 days, mostly to get a handle on the language and writing games in Objective-C. Unbelievably, the game rose to be the number one free application on the iTunes store. I put some ads in it and the cash started pouring in. I mean, more money than I could believe. Of course, it had its peak and eventually slid down the chart and made less money, but even now, it’s doing amazingly well in terms of ad revenue.

Hitting it big like that was a blessing and a curse. All I had to do, I figured, was do a handful of apps like that a year, and I could retire rich, buy an island somewhere and … ok, back to reality. Seems I wasn’t the only one who got the idea of making it big in the app store. I released a bunch of other apps – some free with ads, some paid, some lite/full version, etc. All told, the total amount I’ve made via all my other apps is equivalent to about what I currently make in a single day on Falling Balls. So, I’ve pretty much given up on striking it big AGAIN with iPhone apps, but will continue to give the occasional tweak to Falling Balls to keep it active.

At Infrared5 as well, we hitched up to the iPhone bandwagon. It wasn’t hard. All we had to do is say that we did iPhone stuff and after that pretty much everyone coming to us wanted us to do iPhone apps for them. I did one Flex job early in the year, but since then it’s been pretty much flat out iPhone projects for clients.

A lot of people have actually been upset with me for “abandoning” Flash here. I’m not even going to defend myself on that one. I pretty much did abandon Flash for quite a while there. I can’t say I’m diving back into it both feet at the moment, but I did get pretty burnt out on the iPhone stuff as well. Still working on iPhone stuff at work, but don’t have any ongoing personal iPhone projects at the moment, or any solid plans for any. I love the platform and hardware and capabilities and even got to love the language. But I hate the business model and publishing stranglehold that Apple has on it. In Flash I can bang out a SWF, put it on my site, blog or tweet about it, and in minutes, the whole world can see it. With the iPhone, I have to submit it, wait some unspecified amount of weeks with no feedback or anyone to communicate with, to see if it is approved or not. If not, no real recourse. Just fix it and put it back into the queue. It’s awful.

So what now? Back to Flash? Possibly. As you may have noticed, I had a whole game programming thing going on there a few months ago. Did a whole bunch of research on game architecture, applying it all to Flash games, spoke about game architecture at Flash on the Beach, and promised a game framework/toolkit “Asobu” that I was working on. Not sure what really happened with that.

In fact, for about the last month or so, I’ve hardly done any coding at all in my own spare time. Of course, I’ve been doing plenty at work, and that’s going fine. But usually when I get home, I have some personal stuff I’m working on – a game, some generative art, some experiments, components, a book, or whatever. But lately, I don’t know. I just get home, eat, relax, read some, hang out with the family, light up the wood stove and relax. I’m not particularly worried about it, and you shouldn’t be either. I think my mind just needs some time to recharge. I’ve been going at this pretty hard core since 2001 anyway. Consider I’m on a mini-personal-sabbatical. You might have noticed the dearth of posts here in the last several weeks. In fact, this is the first post I’ve done this month. I’m not going to make any promises about how I’ll now kick everything back into gear and get going on stuff again, but I have no doubt I’ll get fired up again sometime soon. I’ve learned to trust my instincts. They’ve done well for me thus far, and right now they are telling me to chill out.

One thing that I’ve given a lot of attention to in the last few months is running. I started up the Couch to 5K program to get in shape at the end of last August, and now I’m running 5 days a week. I’m completely addicted. Reading lots of running magazines and books and sites. Naturally, I’m getting all geeky about it with GPS and heart rate monitoring and tracking applications, etc. In fact, it has taken over my other, “personal” blog at http://www.keithpeters.org. If you are ever in doubt as to whether or not I’m alive, you can always check there and see what’s up.

But I haven’t been totally code free. In fact, I have actually been doing some ActionScript projects, particularly over this little vacation I’ve been taking. Tying in with the running, I started parsing the raw output of my Garmin Forerunner 305 GPS running watch – parsing the XML and graphing it out in interactive 3D. So much better than any of the apps that map the route on a google map and give you a 2D chart underneath it showing speed, elevation and heart rate. I plan to continue working on that over the next few weeks and have something to show. Also, I revived a cool project I’d started a long while back using the Flash 10 sound synth stuff. Been working on that actively the last couple of days. I actually started getting very excited about the possibilities of that, so that may be the next major thing you see coming out of this place.

What about overall 2010 plans? Can’t really say just yet. At work, we are starting in on a very major, and very … unique project that would possibly be done in Unity 3D. So I may be diving into some C# work for that. And beyond the Flash projects I just mentioned, I’m really interested in learning some other experimental technologies. I started playing with Structure Synth a while back, which is very interesting. A whole new take on programming. Hard to wrap your head around the syntax at first, but produces some stunning pics. I also want to dive more into some things like NodeBox, Context Free, ToolBox, Processing, and Open Frameworks.

Beyond that, like I said, just going with my intuition. And I intuit that 2010 will be a good year.

After only 11 days in approval, RoboDancer has hit the app store. I guess it pays to write blog posts about long waiting times.

Check it out here

This is really nothing but a fun app that I had a fun time making. It hearkens back to a small Flash piece I saw on the web close to ten years ago (which you can see here).

Basically, you have a robot on your screen. Fire up some music and start clicking and dragging to change the way the robot dances. Or shake the device to come up with a random dance. There are 10 interchangeable heads, tops, bottoms, and sets of hands, meaning 10,000 possible different robots, plus a few different backgrounds.

The first app I submitted to the app store back in January was approved in something like 3 days.

As the year went on, that figure went up to around a week, 10-12 days, two weeks, over two weeks.

I have people telling me now that they are experiencing waits of up to 20 days. So my guess is that by the end of the year, we’ll be topping 3 weeks.

Now, I assume that it doesn’t take 3 weeks of testing to see if an app is approvable. In other words, some QA dude doesn’t sit down with it and work on it every day for weeks. Or it doesn’t go through a line of something like 20 people, who each have one day to do their thing with it. And I doubt they do some kind of stress test where they install and run it on a phone and leave it running for a few weeks to see what happens.

My guess is that it takes maybe half an hour to approve or disapprove an app. Maybe more, maybe less. Even if you are ridiculously gracious and say it takes them half a day per app, what accounts for the 3 weeks wait? It’s obvious – there’s a backlog.

So when you submit your app for approval, it goes into a queue. That queue is so damn big that it takes all the Apple approval techs working full time up to three weeks to even getting around to looking at your app.

Backlogs are funny things. Generally, if you have a backlog, it grows. Why? Theoretically, backlogs can either grow, remain the same, or diminish. But if is diminishing, it’s because you are handling things faster than they are coming in and catching up on the backlog. If it is staying the same, it’s because you are handling things at the same rate they are coming in (but not catching up). But the very fact that you have a backlog in the first place indicates that things are coming in faster than you are handling them. So unless you’ve drastically changed how fast you work, or the amount of things coming in drastically reduces, it’s going to continue to grow.

The app approval backlog has steadily grown all this year. That indicates that it’s only going to get worse and worse, because the fact that it is growing shows they are falling behind more and more. Furthermore, the number of overall apps being submitted is increasing. And even worse, every app in the store means potentially several updates, which go through the same approval line. So I predict it’s going to get exponentially worse.

The only solution is to drastically change the way the approval process works. I don’t know how it works, so I can’t particularly say how to improve it. But I hope Apple is doing SOMETHING. At the rate it’s going it’s going to mean multiple month wait times for app approval by some time next year, which is no way to run a business.

I’ve been holding my tongue on this since the announcement, and slowly putting my thoughts together in what I hope is not considered to be a knee jerk reaction.

First of all, a big dose of respect to the engineering team that made this happen. You guys are God-like. I think it’s an amazing feat of technology that you got this working to the point where apps developed in Flash not only run on an iPhone, but were submitted to and accepted by the app store. So anything negative I say is not in any way directed to you guys. Unfortunately, technical awesomeness does not always directly correlate with practical usefulness. God knows I’ve created some things that I considered pretty cool feats of technology, but that were absolutely useless in the long run.

My first reaction on hearing the announcement was that people were going to be awfully disappointed. Yes, it’s an amazing announcement and everyone was very excited about it. But remember when you were a kid and you saw all those commercials on TV for such and such a toy, and you waited and waited for your birthday or Christmas or whatever, tingling with excitement, and then you opened it up and started playing with it and realized that after all, it was just a cheap piece of plastic, with only a fraction of the awesomeness you envisioned? That kind of disappointment. I expected that for one, that disappointment would be in the APIs. The iPhone has a rich set of APIs and Flash has its own rich set. I expected a small subset of both. To my surprise, Adobe has actually done a really good job of getting most of what’s in Flash functioning on the iPhone, and most of what’s natively available on the iPhone accessible from Flash. I haven’t used them yet, but from the way they were described, they seem surprisingly complete. So again, more respect on that end.

However, I still think people are going to experience that Christmas morning disappointment when they start working with this, based on performance. Take a look at the resources Adobe has listed on Labs and the recorded MAX session. And check out the apps that have been released. Almost all of them have comments complaining about performance – slow, choppy graphics and animations, unresponsive UIs, etc. From my own observations, those of others, and even from those who created them, the consensus is that they are very choppy on an iPhone 3G, somewhat better on an iPod Touch 2nd Gen, and “acceptable” on an iPhone 3GS or the latest iPod Touch.

Personally, out of the several apps I have tested on my iPhone 3G, none of them are at the level where I would have released them. Now this isn’t necessarily a bad thing in itself. There are other high performance 3D racing and sports games that take advantage of the advanced features of OpenGL ES 2.0 and therefore require a 3GS. But the things that are choppy and not performing well are the simplest of simple animations and transitions. These are not the kinds of apps and games that should require lots of processing power. If you’re going to specify that your game requires the highest end hardware to function adequately, that carries with it the concept that it is using that hardware’s extra power to deliver an over the top experience. To demand the top end processor just to make simple animations not look like crap is not acceptable.

Now, of course, this is a very early beta or even alpha of a brand new, budding technology. I have NO doubt that it is going to improve. I do have doubts on how much it is going to improve. I would assume or at least hope that it would get to the point where the games such as have been released are at least acceptable on an iPhone 3G.

But my initial point was that people are going to be disappointed. Yes, if Adobe pulls it off, you’ll be able to do some basic animations that perform relatively well, but as soon as you start doing anything remotely complex, you are going to be back in a world of choppiness. That’s my prediction, and I’m willing to eat crow on it if Adobe proves me wrong. But I can imagine people looking forward to converting their PV3D-based stuff to the iPhone, or something with multiple, parallax backgrounds scrolling around and dozens of enemy characters flocking here and there. These are things that perform fine in Flash natively, and things which, if you are using the correct tools, are not a problem at all to accomplish on the iPhone. But I am highly skeptical that the Flash to iPhone route is ever going pull off things like this with any kind of decent performance.

So a lot of people have said stuff like, “Well, yes, I understand this is just for simple, basic games. I’m OK with that.” Well, that’s cool. I’m not going to rain on your parade. If you have a realistic expectation of what you can do, and that’s all you want to do, and you are happy with that, then be happy. Particularly, if you have been developing Flash applications for mobile, you probably have a good idea of what you can do there, and as long as you keep those expectations about the same for the iPhone, you should be pretty happy. However, I will say that a trivial application or game like that is the ideal kind of project to learn Objective-C with. Why not make the leap? You’ll learn something new and useful and when you want to make something more complex, you’ll know how and won’t be arbitrarily stopped.

There’s one thing that really concerned me after the announcement. It was the number of Flash developers in the community saying, “We are all now iPhone developers! Yay!” and “Whew! I don’t need to learn Objective-C now. I’m throwing away all my Objective-C books!” I still believe the bottom line is, if you are serious about developing for the iPhone, you must learn Objective-C. For God’s sake, it’s NOT THAT HARD! Be a professional. Learn a new language. If you are even moderately skilled with AS3, you will be able to pick up Objective-C inside a week. Yeah, the memory management stuff will probably continue to challenge you for a while – I’m still coming to terms with it – but in general, you can be up and running in Cocoa in no time.

OK, so you are a Windows person and don’t have a Mac. So what? Get a Mac. If that’s your sole reason you are holding yourself back from doing iPhone development, and you think that Adobe has solved that for you, I’m sorry, but you are delusional. I wanted to play with Silverlight a bit. What did I do? I bought a PC. Hell, if you are developing for Flash, you are developing for both platforms and you really should have access to both platforms anyway.

Moving past performance issues, there is a huge amount of control you lose in the Flash to iPhone flow. Yes, memory management is a pain in Objective-C, but it has to be done. How does the Flash compiler do it? No idea. Hopefully really well, because that’s what you are stuck with. And it’s not just memory management. Every aspect of an application gets filtered through the conversion process and the Adobe API. There are only a handful of developers using it on just a handful of games so far, but wait until it gets into the real world. I can imagine major pain. As an example of what I mean by this, and one I made on Twitter, check out any of those apps or services that make Flash web sites for you – you know, where you drag and drop some media, and fill out some forms in some wizards and it spits out a Flash web site. There are plenty of them. If what you want is exactly what it spits out, or the changes you want to make are part of one of the wizard forms, you are all set. But the moment you want to have ANY further control over it, you are out of luck. Granted, you will have more control in Flash to iPhone, but I have no doubt there are going to be major points where you wish you had more control. At any rate, if someone came to you claiming to be a “Flash Developer” and showed you a site made with one of those templates, you would either be pissed off, or just laugh at them. And I think this is essentially why some members of the established iPhone development community are pissed off or laughing at this announcement.

Then there is the Apple reaction. As of yet, completely undefined. There has been speculation about the legality of what Adobe is doing, whether it breaks the developer agreement, whether Adobe reversed engineered anything, whether they are using non-public APIs, etc. Of course, Adobe’s stance is that it’s not a problem. But it’s really up to Apple to adjudicate what a problem is. I’m not even saying that Adobe has done anything illegal or even unethical, but I expect that if Apple can find ANY reason whatsoever to stop it, legally, technically, or otherwise, they will. Yes, several apps got approved under Apple’s nose. I’m interested to see how many will get approved now that Apple know’s what’s what. Some say that they won’t care – that they still get the revenue from the sales, so they will be happy to have more apps coming in. I don’t know. Time will tell. Especially if this does result in a flood of low quality apps, as many are predicting. They have many options. They can just disapprove any app that is made by Flash – maybe let the odd one through here or there to appear fair (and don’t think they can’t tell which apps are made with Flash and which aren’t). Or they could attempt outright legal action against Adobe. Or they could just change some API or app signing procedure or whatever, causing Flash based apps to not be submit-able, and forcing Adobe into a constant game of catch up. Or any number of other responses. I don’t think they will simply do nothing.

Finally, this is just my personal speculation, but I somewhat feel that this is more of a political move against Apple, to somehow force some kind of action on getting the Flash Player onto the iPhone. I don’t know how that is supposed to work, but progress on that front seems to be at a standstill now, and this is no doubt going to stir things up at least. So as technically amazing as this is, I predict that this technology is not a long term strategy for Adobe and I doubt it will be part of CS6.

New features:

• Full rewrite in OpenGL for improved performance and response.
• Basic game looks and runs the same as original.
• Shiny new UI.
• New Advanced and Ninja levels!

The big feature is the multiple levels. A lot of people didn’t like sitting through the slow build up. Now if you start in advanced mode, the balls come fast and furious, right from the start. Choose Ninja Mode and they come at you from both directions. You won’t be bored. If you already have the game, just update it. If you haven’t experienced the glory that is Falling Balls, Get it here!

Last December, I had a bunch of unused vacation time and took a couple weeks off, stayed at home, and learned me some iPhone dev. I submitted my first iPhone application in January and I was hooked. I now have six apps / games in the store (not counting full/lite versions as different), making close to an app per month.

Those are my personal apps. At my job at Infrared5, we are also flooded with iPhone development. I’ve been flat out on iPhone games there for a couple months, and scheduled for another two months forward.

It got to the point where I hadn’t coded a line of AS3 in 2-3 months, and was seriously wondering if I would ever get back to it. But something snapped in the last week or so. I guess I’ve become somewhat disillusioned with the whole iPhone dev game.

So the iPhone App store is just over a year old, which means it’s twice as old as it was when I first got in. And it’s changed a lot. One of my first games, Falling Balls, unexpectedly took off and rose to be the #1 free application. I put some ads in it from AdMob, and was stunned at how much money it was making. Even now, almost 7 months later, it continues to lay a nice golden egg for me every day. I have NO complaints there. The only problem is, it’s like winning at gambling. Once you get a taste of it, you can’t stop, even if you never win again. All of the rest of the apps I’ve released have barely done anything. Not even remotely made up for the amount of time I’ve put into them. I’ve done lite versions and full versions, ads and paid versions, done all the promotion steps, everything everyone says to do. Bug Out! has done the best so far, and is doing OK, but only a tiny fraction of what Falling Balls did.

Now, it is very easy to say that my other apps weren’t very good, and I won’t argue that, but come one… Falling Balls? A stick figure that runs back and forth and gets squished by balls? It literally took me a weekend to make, as a brand new iPhone developer, and only part of that weekend. I guess it has some kind of zany viral appeal, but that’s pretty hard to reliably duplicate.

Also, while that viral appeal is a factor, I think it has more to do with the changing landscape of the app store. In December, when I started learning, there were 13,000 apps there. In January, when I submitted Falling Balls, there were around 17,000. Now there are well over 60,000. As for selling apps, the average prices for apps and games are steadily decreasing, games being lower and more steadily decreasing, with an average of less than $1.50. Even top studios are releasing high end, polished, professional games for $0.99. How can a single do-it-all-yourself developer compete? So I’ve pretty much given up on selling apps in the store.

What remains is releasing free apps with advertising. After all, it worked with Falling Balls. But even the free games market is totally saturated. There are close to 15,000 free games and applications in the store right now. That’s more than the total number of applications that were there when started. If you don’t get in the top 100, you aren’t going to get enough downloads to get enough ad traffic to matter. Of course, if you DO get in the top 100, you could be in for a rocket ride. And there’s the whole gambling / addiction thing again. Chasing that thrill of a big hit.

The problem is, it stops being fun. When I was doing Flash stuff for myself, I was almost always doing stuff with no concept of making money. I was just making cool stuff that I found to be fun. Once you get a taste of profits though, it’s hard not to be in it for the money.

Note, that I’m talking about being a single developer. I still think there is money in doing iPhone apps for the bigger companies who can afford teams of people, and tons of advertising and promotion, and forge whatever allegiances with whatever demons you need to forge allegiances with to get your app featured in the iTunes store, which is like a golden ticket. So I’m not saying the app store is dead, merely that the gold rush days are over, and now it’s big business like anything other market. As a single developer, I won’t deny that you still might win the lottery, but I’m done chasing that dream.

I’m still going to refine and develop Falling Balls, as it’s still in the top 100 games, still making money for me, and with some cool new updates, could go even higher again. I have an update waiting for approval that brings different difficulty levels and should be out in the next few days.

I’m sure I’ll also continue to keep my foot in the door with other applications or games here and there. I love the Objective-C language, and have learned so much from diving deep into it for so long. I’m sure it’s made me a better developer overall. But any apps I do from here on out, will be purely for my own enjoyment. And technically, there is a lot of enjoyment to be had in creating things that use multitouch and accelerometer. It opens up all kinds of possibilities for creative, artistic apps.

But I’m also going back to Flash, and in fact, have started creating a brand new Flash game. I’m having fun getting back into AS3 after such a long hiatus. Pretty rusty though. I’m also realizing some of the things I really missed about the Flash Platform as a whole. I think the biggest thing is the immediacy of it. I can code up something cool, upload it to my server, blog or twitter it, and instantaneously, thousands of people will be able to see it. No waiting. No arbitrary judgement of whether or not my SWF meets certain criteria.

Compare that to the app store approval and waiting game. When I started submitting stuff, it was an average of 3 days for approval. Now it is up to 12-14 days. That’s because app store submissions have about tripled in that time. And if waiting times are getting longer AND submissions are getting higher, that backlog is only going to continue to grow and grow. If I banged out a new iPhone application right now, nobody would see it til much later this month.

The approval process itself is getting a really bad reputation for reasons beyond the wait, as well. One is the arbitrariness of it. So many horror stories. Apps getting rejected for certain reasons, while another similar app with the same “problem” gets approved. Some developers have said that if you get rejected, just immediately resubmit with no changes. Chances are you’ll get a different reviewer who won’t be looking at the same thing the other one was looking at. Or one that’s in a better mood, or at the end of his shift and wants to go home. Or maybe it’s like airport security, where every nth app gets pulled aside and gone over thoroughly. Then there are the apps rejected with no reason given, and the apps which are simply kept in limbo for months, never approved or disapproved. And this week’s scandal with the Google stuff.

Actually, I’ll be the devil’s advocate on that one, and say Apple has the right to reject an app that competes with their own built in apps. They’ve made that explicitly known from the start anyway. But as for the other stuff, I don’t feel like Apple is being intentionally malicious in the delays and rejections, just that the app store has grown larger than they planned for, and they are struggling with the whole process. But it makes for a really bad developer experience. If you do get a rejection, you could be looking at over a month for app approval. That’s ridiculous. And the fact that it’s just a black box is doubly frustrating. You just submit and wait an unknown amount of time. No prediction on how long the wait is going to be. No feedback on where it is in the queue, nobody you can talk to to speed things up or find out what’s happening. If you get rejected, there’s no appeal process. You fix it and put it back into the black box for however long. Again, I don’t think it’s malicious, but it sucks big time. Luckily, in all my submissions, I’ve had only two rejections, which were valid items and easily fixed.

Well, that’s the end of my rant. By the way, all the stats I’ve mentioned here are from this page:

http://148apps.biz/app-store-metrics/?mpage

I can’t vouch for all the stats, but most seem correct except their submission wait times. I have not personally seen a drop off in wait times in the last month, only an increase.

Had an interesting conversation today with Aral Balkan and others via twitter, which began when Aral mentioned some concern over the iPhone analytics package available at Pinch Media.

If you don't know what Pinch Media Analytics is (or analytics in general), there are multiple ways I could describe it. I could describe it as "spyware that secretly gathers information about you and sends it across the Internet without your permission." Of course, that would be a carefully designed statement, specifically engineered and worded to scare you into thinking it was evil and dangerous, and generally just an attempt to create FUD (Fear, Uncertainty, and Doubt). Or, I could go the other way and carefully craft an innocuous description that makes it sound wonderful. But let's instead look at the facts of what it is, what it does, and what it can and cannot be used for.

Basically, Pinch Media Analytics consists of a library that is compiled into an iPhone application and a web service. Generally, when the application starts, it pings the web service with a small amount of information (we'll cover that in a minute) and when the application is about to terminate, it pings the service again. The developer may also choose to ping the service at other various points in the application. These pings are then aggregated on the server into various reports the developer can look at, such as how many unique users have installed the application, how often and how long they are using it, how many times the app may have crashed, even how many "cracked" (pirated) copies of the app are installed (a surprisingly high number). If the developer included additional intermediate pings, one might be able to see how many users are visiting different parts of the app or game, and how much time they are spending on each part.

So, what information is being sent? Let's get the big one out of the way first. It sends, *gasp* your device id! This is the unique hardware id identifying your iPhone. Now that sounds pretty bad, right? But don't go having a big knee jerk reaction and freaking out. It's not like it's sending your social security number, drivers license, credit card, or mother's maiden name. It's simply a unique number that is used to differentiate two different users, so if I had 10 plays of my game today, I can tell whether that was 10 different people or the same person playing it 10 different times. There is no way for Pinch Media or any other developer to link a device id to a particular person. I imagine that Apple could probably do that, since you registered the phone with them and made your account. But unless someone is a serious hacker capable of getting into Apple or AT&T's databases, you don't have much to worry about. And this is not some super secret hack that Pinch Media put together in their evil labs. It's part of the standard, approved, iPhone SDK public API. You just say:

and there you are. Furthermore, this id is used by all kinds of apps. If you've ever played a game and submitted a high score, you've most likely submitted your device id to the server that stores the high score. Chances are that many iPhone advertisements also make use of the device id to know how many impressions or clickthroughs are by unique users, as opposed to one developer clicking on his own add over and over. I'm sure that the device id is used in many other ways by many other apps. So relax about it.

OK, what other data gets sent in the Pinch Media ping? Well, there's an app id, which is a special id assigned by Pinch Media to a specific application, so they know what app to count the ping on. And various data about the hardware or software of the phone, such as whether it's an iPod Touch or iPhone, what model, what OS, etc. It will also send location data, but it does that through CoreLocation, which automatically pops up a dialog asking the user if the application can access location first.

So, if you are running around telling people that Pinch Media is "secretly gathering information about you", it's definitely FUD. The only data that is remotely about YOU is your location, and it needs your permission to do so, so it's not secret. All this is really no more than any web based analytics package can get right out of a browser - what kind of machine you are on, what OS and version, IP address, location, etc.

Now one problem people may have with this (one Aral voiced) is that a web application is on the web, but an iPhone application is like a desktop application that is trusted and installed and should not be "secretly" using any bandwidth, much less sending information, without explicit permission. I can see this point, but honestly, the lines between desktop applications and web applications are blurring more every day and I predict will be irrelevant at some point. And in the case of iPhone apps, I think it is irrelevant. An iPhone is a connected device. It's an Internet device. Most interesting applications do have connectivity as a major component. High scores, dynamic content, web services, multiplayer, etc., etc. And I bet most of these send some or all of the same data Pinch Media is sending. Comparing this to an old fashioned desktop ask that requires permission every time it talks to the net is simply a wrong comparison.

I also know that no matter what anyone says, some people will just be against the idea of any app sending any information for any purpose without express permission. Personally, I feel that is dogmatic, rather than pragmatic. "It's my device, I should be in control of what gets sent where." I see that as dogmatic and I'm not going to argue right and wrong with you. The simple fact is, that if you don't want your device to send any information, you better just shut it off now.

Furthermore, Apple has taken app security pretty seriously. All 3rd party apps run in a very strict sandbox. Other than the information described above (device id, hardware and software versions, etc.) an app only has access to its own bundle - which includes app included and installed by the application itself, and any data the user inputs into the application that the application then saves. There are, of course hooks into other apps, such as the Photo Library and Contacts, but these require user interaction and permission. I can't write an app that just reads all your contact info and photos and uploads them to my server behind your back.

The final point I made on Twitter was, "analytics != spyware", since the s-word was being tossed around.

Spyware is intentionally malicious software, or malware. It is designed to collect personal information about a specific user and make use of that information to exploit that user or his/her machine in some way, and often does harm to the device it is installed on as well. Malware is often illegal and almost universally frowned upon. To call any legitimate analytics package spyware is completely unfair. Analytics sends aggregated anonymous data. The purpose of using a package such as Pinch Media's is to see how your app is being used and how you might improve it to make it a better experience so that people will use it more. In my book, that is not malicious by any stretch of the imagination.

In my recently released app, Wire Draw (which you can read more about here) I wanted to create a color picker to allow the users to choose the colors of lines. Unfortunately there isn't a color picker control in UIKit. I did find one on line, with full code on how to implement it, but that was a full screen affair and I just wanted something that would fit nicely into the existing settings UI. I finally decided on RGB sliders, which are easy enough to implement, but not very visual. I wanted the user to know instantly which was the red, green, or blue slider. I finally came up with what you see here:

I'm not saying it's perfect, but it worked pretty well for me.

Skinning the sliders wasn't the most obvious thing in the world to do, and I'm not sure I've seen any other apps that do it (I'm sure there are), so I thought I'd share what I learned.

First of all, create your slider. You can create and position it in code, or do it through Interface Builder. If you do the latter, make sure you create an IBOutlet for it and make the connection to that outlet in IB so that your code has access to the slider. All the skinning is done via code. We'll assume your slider is named "slider".

If you select the slider in Interface Builder and look at the Attributes Inspector, you will see two dropdowns for Min Image and Max Image. These allow you to put little pictures to the left or right of the slider. Say you were making a volume control. On the right, at maximum volume, you might want an icon that showed a little speaker with sound waves coming out. On the left, zero volume, you might want a speaker with no sound waves, or maybe even an "x" through it. That's pretty simple, but is not what I'm talking about when I say skinning. Again, to skin the actual slider itself, you need to leave IB and write some code.

The methods that affect the appearance of the slider are:

Let's start with the thumb. This is the button that you press and move back and forth. Create a new image to use for this. I recommend you use a transparent png file, around 24x24 pixels. Here's what I made for my red slider:

Add that to your projects. Then add the following line of code, somewhere where it will run early and once, such as viewDidLoad of the view controller where the slider is located.

This tells the slider to use the specified image as the thumb in the normal state. Actually, if you only specify the normal state, it will be used for all states. If that works for you, that's all you have to do. If you want a different thumb to show when the user is pressing it (not that they'll be able to see much of it with their finger over it), add another line with the other image and UIControlStateHighlighted for the state. You can also specify another image for UIControlStateDisabled. There are other UI Control States, but I'm not sure any of the others apply to a slider, so those are the three you'll most likely be using.

But say we just stick to the normal state as above. We run the app and we get this:

Hmmm... well, thumb skinning was successful, but we lost the rest of the slider! It seems that slider skinning is an all or nothing proposition. So let's get to work on the tracks. As you saw, we have methods to set the minimum and maximum track images. But what does that mean exactly?

Simply put, the minimum track image is the image of the track that appears to the left of the thumb, and the maximum track image is what appears to the right of the thumb. Again, these have states that work just like the thumb image. Let's just use normal for now, which covers all states.

I made a red track image which looks like this in it's raw form:

I also made a black one you can see here:

The red track will be the minimum image and the black track will be the maximum image, which will give you the effect you can see in the final screenshot at the beginning of this post. But you'll notice that these track images are very small. That's fine because they will be stretched to fill the entire space from the edge of the slider to the thumb. This is great if your track image is a solid fill rectangle with no shadows or anything. But let's see what happens if it's not, like the ones we are using. You can already probably figure out how to apply these images, but I'll give you the code anyway:

Run that and we get this:

Ouch. Yeah, it stretched them all right, along with the curved corners and shadows. Now, if you've come from the Flash world, you're thinking, "Scale9!!! Use Scale9!" And right you are! There is an distant cousin of Scale9 in UIKit, called a "stretchable image". You can create a stretchable image by taking a regular UIImage and calling the method, "stretchableImageWithLeftCapWidth:topCapHeight:" on it. This creates a new UIImage which can be stretched while not distorting the edges and corners, just like Scale9 in Flash. However, I said it's a distant cousin, and it really is quite distant. Although they has the same end effect, stretchable images are defined quite differently. As you see, we only pass in two parameters: leftCapWidth and topCapHeight. What about the right and bottom? Well, those are kind of dynamic. Here's how it works:

The leftCapWidth is the margin on the left side of the image that will not be stretched. The right cap width (although there is no actual variable named that) is the remaining width, minus one pixel. Alright, that's not very clear. We need a drawing.

Ignoring the topCapHeight for now (which you can do by setting it to zero), we see we have an image that is 21 pixels wide. If we set the leftCapWidth to 10, that means the first 10 pixels will not be stretched. What will be stretched is the next single pixel. Only that pixel and nothing more, and it's always just one pixel. Finally, everything to the right of that single pixel will not be stretched. So, in the above example, the image is 21 pixels wide. The leftCapWidth is 10, then there is one stretchy pixel. That leaves the right 10 pixels as not stretchable, which would be your right cap width, if such a variable existed.

Note that while my example is symmetrical, it doesn't have to be. If I had made the leftCapWidth 5, then the right portion would have been 15 (21 - 5 - 1). Or if the whole image was only 20 pixels and leftCapWidth 10, the right portion would be 9 (20 - 10 - 1). Again, the stretchable area is always 1 pixel, so I don't think it's too easy to stretch a gradient like you can do in Scale9 in Flash (not that it usually works out too well anyway). If you are into formulas, the width of the right portion is total width - leftCapWidth - 1.

The topCapHeight works exactly the same way, but we don't need it here. Let's put this into action. Rather than massively nested brackets, we'll create a reference to the two stretchable images.

And that give you this:

Yay!

Note that in this case, I could have made the right edge of the red track perfectly square, and chopped it off at 11 pixels. This would mean that the first 10 pixels would not stretch, the next (and final) pixel would stretch the rest of the distance, and nothing would be left over on the right side. Either way would work here, because the right edge of the track is hidden under the thumb. The inverse could be done for the black track.

Well, that's all folks. Hope this makes a short part of your day a bit easier some time in the future.