Blog

Thoughts on mobile app development.

An Interview with Beginning iOS Dev

I was recently asked by Beginning iOS Development if I would like to take part in an interview, which sounded like fun to me. We discussed a range of things, including marketing, designs, my background, and development life in general. I’m really happy with how it all turned out, so if this sounds like it might be of interest, wander on over and have a read: http://www.beginningiosdev.com/interviews/interview-with-ben-williams-of-aspyre-apps


Enjoyed this post? Think we’re clever? Subscribe via RSS or follow us on Twitter.

Freelance or In-House?

I’ve been calling myself an iOS developer for a bit over 3 years now, and during that time I’ve released quite a number of apps on to the App Store. Some of these have been in-house apps that I’ve developed for myself, and some have been work-for-hire apps that I’ve written as a freelancer. As I’m an independent, the choice of where I spend my time is up to me, but I often find it difficult to know the answer to that choice. This post will explore some of those options.

At one end of the scale, you might spend all of your available time working on your own apps. I’ve been lucky enough to work on some really great contract jobs, but none of these are quite as satisfying as taking your own idea all the way to version 1.0. I’ve also been fortunate enough to have had apps featured on the App Store, not once but several times. There’s plenty of money to be made on the App Store and the dreams of getting inside that Top 100 do sometimes come true. However, it’s a tough market. You need a certain combination of skill, luck and persistence to succeed in the App Store, and there’s a good chance that you’ll spend months on your dream only to find it sells less than a few copies a day. In my mind, throwing all of your weight behind in-house app development is the riskiest, but potentially the most rewarding (both financially and emotionally). I think the key to success is keeping a close eye on the market, and developing a keen interest on the strategy & business side of creating apps, instead of just the coding.

On the other hand, you could spend your time doing freelance work. iOS developers are in huge demand at the moment, and if you’ve got the skills there’s plenty of good projects out there. Apart from the obvious development skills required, you also need a certain element of people skills – you’ll never be a successful freelancer if you don’t know how to make your clients feel at ease. This doesn’t come naturally to most developers, but with a bit of practice everyone can do it. The main difficulty then comes down to finding work. A lot of this is all about making connections, going to conferences, going to local developer meetups, being involved with the community, blogging, and so on. Freelance work can also open you up to working on some very cool projects, especially if it’s with big brands whose apps are bound to get a lot of downloads. This sort of thing also feeds back into itself – the more freelance work you do, the better your portfolio looks, and so the easier it is to get more work.

There often seems to be a bit of an argument over whether you should charge by the hour or quoted amounts for freelance work. I’m a strong believer that quoted amounts are the way to go. Yes, sometimes you lose out and a job takes longer than you estimated. This is a great incentive for learning how to estimate properly, and track your time sufficiently. It also gives you clients peace of mind that their costs will be relatively fixed unless they change the scope. Removing the uncertainty of how much a project is going to cost gives you a big advantage over other freelancers. And of course, for every job where you don’t underestimate, you overestimate – which works out in your favour.

Another option to consider is whether you should keep your costs low, but ask for a percentage of sales in return. If you’re doing freelance work, you’ll hear this proposition a lot. My advice is to steer well clear of it. Unless you are positive that the idea is definite winner, it’s not worth risking your time and money on. Not only will this app be entering a very crowded market, but you’re also relying on the client to create income for you – which all comes down to how good their app really is, and how good they are at marketing and supporting the app. I believe in creating my own destiny rather than relying on others, and so I almost always insist on full payment for the job. If the client believes in the app that strongly, then they should be willing to pay for it to be developed in full.

So, there’s a few different options there, and if you have any others I’d love to hear about them. I’m fortunate enough that I have a few good clients who keep sending work my way, and so I usually let them dictate my time. If a project comes my way, I’ll work on it, and in the down-time I work on my own apps. This provides enough of an income in order to support myself, whilst slowly building up my own portfolio of apps (and passive income). Sometimes this can be a little frustrating as a lot of work will come in all at once, and I’d rather be working on my own apps, but I’m the first to admit that it’s a good problem to have. And until I hit on that winning app which gets all the way to number 1, it’s a necessary one as well.

GeekDesk Max – A Standing Desk Review

As far back as I can remember, I’ve wanted a standing desk. There’s plenty of research out there which indicates that sitting in a chair all day isn’t good for you, but this has never really been much of an influence on me. I simply believe that with most things in life, the key is moderation – and sitting for 8-10 hours at my desk, continued by several hours of sitting whilst eating dinner, watching TV or reading, isn’t moderation.

Keeping this in mind, the main feature I wanted in such a desk is that it’s quick and easy to change the height. I like the idea of switching between standing and sitting throughout the day. I believe you are losing a lot of the benefits by using a desk that is intended to stay at one height, even if that height is standing. Similarly, the height needs to be easily adjustable. The more difficult it is to change height, the less likely you are to do so regularly.

I’d always heard good things about GeekDesk, who specialise in height adjustable desks. Unfortunately for me, they never had something that suited my needs – that is, until the GeekDesk Max came along. The Max has a range of 23-49 inches, but most importantly, it has programmable presets. It sounded perfect, so I decided to pull the trigger.

As I live in Australia, I needed to have it shipped internationally, as well as with a different power supply. All this really meant was that a few emails were exchanged to place the order, rather than buying directly on the GeekDesk website. Really, the process was simple. Unfortunately, when my GeekDesk arrived some parts had suffered damage in transit. I still don’t really know how this happened, as the parts were pretty well packaged, and the boxes themselves didn’t seem to have been damaged much. Regardless, the GeekDesk support was very helpful, and although it was annoying having to wait for replacement parts, the issue was handled perfectly. How a company handles things when they go wrong can speak volumes.

Once I had all the parts, it was time for construction! It took me roughly 3 hours from start to finish to put everything together, but if I’m being honest, most people would do it in half the time. It was the weekend and putting things together is part of the fun for me, so I took my time. The instructions are clear, and there’s some nice spots for hiding all the cables away. Once the desk is setup, you’d barely know it was anything but a regular desk.

Changing the height of the desk is super simple. Press the up button, desk goes up. Press the down button, desk goes sideways – just kidding, it goes down. Being able to key in presets though is the real power of the Max model. All I need to do is press the number 1 button, and the desk raises up to the perfect standing height for me. Press number 2, and roughly 20 seconds later I’m all ready for sitting. The operation is very smooth, and much quieter than I would have expected. The desk also has an acceleration/deceleration curve, so it doesn’t stop suddenly when it gets to the pre-programmed height.

If you’re still reading, you’ve probably got the point by now – the Max is a fantastic height adjustable desk. It’s solid, works very smoothly, and it couldn’t be easier to change heights. But what’s it like to actually use?

So far, it’s fantastic. I’ve spent the last 2 days switching between standing and sitting every half hour. The 20 seconds or so that it takes to change the height gives me a good chance to shake out my legs. It’s much easier than I expected to stand for a period of time, and I love being able to just walk in and out of the room as I please. I don’t know why, but it feels so much nicer to walk up to your computer, rather than plonking yourself down in a chair.

I’m quietly confident that I’ll never go back to sitting all day ever again.

Thoughts on iOS 6

iOS 6 is no doubt still a long way from being released, but I think if you’re a serious app developer, it’s time to start giving it some thought. Apple has a tendency to feature apps that show off the platform, so working in some features of a newly released version of iOS is a good strategy for getting your app on the front page of the App Store. I have no inside information, but I think it’s still possible to take an educated guess at some of the things we’ll see in iOS 6. Here they are in particular order.

Siri API

I think this is a feature many of us are hoping for, but it could go either way. Technically Siri is still a beta product – a pretty rare occurrence for Apple. I’d be surprised if they managed to turn around a beta product in 12 months to one that has full third party support. Still, I have no doubt that they’re working on it, and if it doesn’t appear in 2012, there’s a good chance it will in 2013.

Better Cross-App Communication

Let’s face it – Apple’s competitors currently provide better options for cross-app communication. Sure, we have URL Schemes, but both Android and Windows Phone 7 have much better options. Apple is really great at crossing off items from the list of “Things Competitors Do Better”, and I think there’ll be some nice improvements in this area for us to play with in iOS 6.

Share Everywhere

We’ve already seen some hints of this in OS X 10.8, so I think there’s a good chance we’ll see some improved sharing controls in iOS 6. Although the chances are low, I’d love to see some built in Facebook sharing functionality.

Notification Centre Widgets

Historically, I believe Apple has always liked the idea of widgets. Although they never really made it into iOS, they certainly were given some serious thought. Now that we have the weather and stock widgets in Notification Centre, I think it makes total sense to open this up to third parties. You’ll have a set amount of space to work with, and data calls will only be allowed when Notification Centre is activated. Some developers are going to come up with some really nice ways to use this feature. Personally, this is an area that I’m going to concentrate on.

NFC

Although this is more of a hardware feature, the possibilities for neat things you could do with Near Field Communications are endless. If NFC finally does make it into the iPhone hardware this year, I’m expecting it to be fully locked down – no third party integration for us this year (much like Siri is now). Still, it can’t hurt to start thinking about what sort of things we could do if we had some NFC APIs.

Better Location Support

Apple has already started playing in this area in iOS 5. The Reminders app is a classic example, allowing you to set off a reminder when you leave or enter a certain region. I expect we’re going to see some even cooler things in this area in iOS 6, although I can honestly say I have no idea what!

Release Date

I’m betting the release date will be early October – the same time period as iOS 5. This date makes a lot of sense for Apple, as they can hold off announcing iOS 6 until WWDC. What better venue to announce the new features of iOS than at the premier Apple developer conference for the year? I think there’s very little chance Apple will introduce new iPhone hardware at WWDC this year, and this gives developers a few months to get up to speed before the public release later that year. The iPhone 4S is selling ridiculously well – it just doesn’t make sense for Apple to cut it off early. Finally, an October release is just around the corner from Christmas, perfect for a booming quarter.

So that’s everything on my list. What about yours?

How to Desaturate a UIImage

I recently needed to figure out how to take a photo with the camera, and then desaturate it. I needed to control the level of desaturation, ranging from completely greyscale, all the way up to the original image. This turned out to be trickier than expected, but in the end the solution was quite simple.

The first useful looking bit of code I found was on StackOverflow. This code was quick and easy to implement, and works nicely, but unfortunately gives no control over the amount of desaturation. It completely converts the image to greyscale.

StackOverflow then produced another promising looking solution. The DesatView seemed exactly what I was after – create the view, assign the image, and set the desaturation level. Unfortunately, even setting the level to 100% seemed to result in purple blotches on my photos. I’m not sure why, but it seemed to be altering the hues somehow, and I didn’t know enough about it (or have the time) to figure out why.

Next, I came across the GLImageProcessing sample code from Apple. This is an OpenGL ES project, which demonstrates how you can alter the brightness, contrast, saturation, hue and sharpness of an image. As you would expect, the sample code works really nicely, and in fact allows you to both saturate and desaturate an image. I don’t have any OpenGL ES skills but it wasn’t too hard to integrate Apple’s code into my project. Unfortunately for some reason I just couldn’t get the saturation working. I had no problem with brightness and contrast, but saturation just wouldn’t work for me. I’m sure I was doing something wrong, but time was against me.

The solution I settled on turned out to be pretty simple, and in fact used the first greyscale method mentioned at the top of this post. The answer is to create two UIImageViews, with one on top of the other. Assign the same UIImage to both, and then convert the bottom UIImageView to greyscale. By then altering the opacity of the top UIImageView, you get a cheap and easy desaturation effect. If you need 40% desaturation, set the alpha value of the top UIImageView to 0.6. Simple.

If you then need to create a UIImage out of the result, this is pretty easy too:

[code]
UIGraphicsBeginImageContextWithOptions(self.view.bounds.size, self.view.opaque, 0.0);
[self.view.layer renderInContext:UIGraphicsGetCurrentContext()];
UIImage* desaturatedImage = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();
[/code]

This creates a UIImage object out of whatever is currently displayed in the UIView object – you can even use this for subviews, if you don’t want to save out your whole UIView.

This turned out to be a good lesson for me. There’s always more than one way to do things, and the simplest solutions are often the best. It may not be the most performant solution, or even the most intuitive, but the main thing is that it solves the problem. The bonus is that it’s quite an elegant way of doing it, as well.

Page 3 of 1012345...10...»