Archive for the 'iPhone' category

The iPhone App Store Approval Line is Doomed

Nov 01 2009 Published by under iPhone

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.

23 responses so far

My thoughts on Flash CS5 and iPhone

Oct 13 2009 Published by under Flash, iPhone

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.

99 responses so far

Falling Balls 2.0

Sep 08 2009 Published by under iPhone

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!

9 responses so far

iPhone Dev: The Honeymoon is Over.

Aug 01 2009 Published by under Flash, iPhone, Objective C

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:

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.

34 responses so far

Spyware vs. Analytics

Jul 28 2009 Published by under General, iPhone

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:

[c]UIDevice *device = [UIDevice currentDevice];
NSString *uniqueIdentifier = [device uniqueIdentifier];[/c]

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.

13 responses so far

Skinning UIKit (iPhone) Sliders

Jul 26 2009 Published by under iPhone, Objective C

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 24×24 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.

[c][slider setThumbImage:[UIImage imageNamed:@”redThumb.png”] forState:UIControlStateNormal];[/c]

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:

[c][slider setThumbImage:[UIImage imageNamed:@”redThumb.png”] forState:UIControlStateNormal];
[slider setMinimumTrackImage:[UIImage imageNamed:@”redTrack.png”] forState:UIControlStateNormal];
[slider setMaximumTrackImage:[UIImage imageNamed:@”blackTrack.png”] forState:UIControlStateNormal];[/c]

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.

[c][slider setThumbImage:[UIImage imageNamed:@”redThumb.png”] forState:UIControlStateNormal];

UIImage *minTrackImage = [[UIImage imageNamed:@”redTrack.png”] stretchableImageWithLeftCapWidth:10 topCapHeight:0];
[slider setMinimumTrackImage:minTrackImage forState:UIControlStateNormal];

UIImage *maxTrackImage = [[UIImage imageNamed:@”blackTrack.png”] stretchableImageWithLeftCapWidth:10 topCapHeight:0];
[slider setMaximumTrackImage:maxTrackImage forState:UIControlStateNormal];[/c]

And that give you this:



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. 🙂

11 responses so far

Wire Draw released!

Jul 26 2009 Published by under iPhone

Remember, it’s free. Have fun with it. 🙂

One response so far

Falling Balls rewrite

Jul 19 2009 Published by under iPhone, Objective C

This is what I’ve been up to:

One response so far

Coming Soon: Wire Draw for iPhone

Jul 18 2009 Published by under iPhone

[Edit: as of today (July 26), the app is now available in the app store. Get it here.]

The latest iPhone app / game from Wicked Pissah is Wire Draw.

Screenshot 2009.07.12 17.58.20

This app lets you draw lines and shapes in 3D. Alter line width and color. Rotate your drawing around in 3d using the device’s accelerometer. Even draw while rotating.

Screenshot 2009.07.12 17.58.57

Fog features provides atmospheric effects where lines further from the camera fade out. Fog is adjustable in the settings for anything from a serious pea soup to barely perceptible.

Screenshot 2009.07.12 18.02.54

An on screen grid can be toggled on or off to help you draw.

Screenshot 2009.07.12 18.01.25

Finally, you can save your images to the iPhone and pull them up again to show your friends.

Screenshot 2009.07.12 17.59.52

The app is completely free. Kids love it. My 6 year old daughter stole my phone for an hour when she discovered it. The app was submitted a week ago today. Currently, Apple is taking close to 2 weeks on the approval process, so it should be out some time in the coming week.

9 responses so far

iPhone App Dev Business Models.

Jul 14 2009 Published by under iPhone

I saw a message from someone on LinkedIn today, asking about “luring” iPhone developers to do a project, by offering them a revenue share in order to “minimize the overhead”.

I thought that was pretty interesting. Here was my response:

Good app ideas are a dime a dozen. Your great idea isn’t guaranteed to make any money in the app store. Why should a developer develop your whole app for just a percentage of the money you are going to make? Just because you have a good idea? Most developers have good ideas too, and if they are going to risk not making anything for their hard work, they might as well balance that by doing their own work and making 100% of the profits.

So you have to ask what you are bringing to the table beyond your great idea. Marketing? Promotion? Something that will guarantee high sales? But if you are so sure about high sales, then why not just pay the developer for his / her time? If you are trying to mitigate your cost by only paying the developer IF the app makes money, then you are not so sure that it will. So again, what are you really bringing to the table?

To put it another way, this is your business venture. You are investing in your product and your idea. Part of that investment is development cost. I think you are not looking for a developer, but looking for a business partner that happens to be a developer. He’s going to invest his time in the app. So again, what are you bringing to the table beyond the idea for the app?

I think most developers, when they look at working on someone else’s project, are not at all interested in investing in an idea. They are looking to do some work and get paid for it. They will deliver you an application and it’s up to you to make money from it. If you find one willing to work on a percentage basis, good for you. But I think it is going to be hard, and will get harder as people realize more and more that the app store is not a guaranteed gold mine.

I don’t really have much more to say about it than that. I’m not saying that this could never be a good arrangement. There could be a situation where there’s an existing successful app on another platform that the customer wants ported to the iPhone. Or a brand name that would help guarantee sales. I’m sure there are other situations where this would work. Actually, my company is doing a project on this kind of basis, where the customer is bringing some pretty major stuff to the table. But simply having a “good idea for an app” is pretty lame.

19 responses so far

« Newer posts Older posts »