Over the years the steady progression of web technologies like HTML, CSS and JavaScript, has meant we’re now able to replicate many of the UI elements and interactions you see in native applications using web technologies.

With that in mind, I’d like to go over a couple of ways we use web technologies in our apps and workflow here at Realmac.

Before we go any further, let me say this: in my opinion, building an entire app using current web technologies just doesn’t cut the mustard. It’s clunky; interactions and animation are jerky or delayed by a split second. Things don’t quite work how you expect them to.

We may see this change in the future (with better JavaScript rending and new HTML and CSS features being developed), but today web-based apps aren’t on the same level as native apps.

Don’t believe me? Facebook recently re-wrote their iPhone app to be native due to performance issues with the HTML version.

Where I do think web technologies have an advantage over native is when prototyping features. It’s so quick and easy to put together a web page with an element(s) that you want to get a feel for. This is especially true when working within a team; there’s no provisioning profiles or app updates to install, just send out the URL and anyone can test and give feedback.

Another benefit is happy coincidences. When we were building the Analog site, I was coding up the filter switching animation and it got us thinking about adding the animation to the app. If you’ve not seen the animation, go check it out on the site, but basically there’s a bar that swipes back and forth across a photo, removing the old filter and applying the new.

It was so quick to build (finished in literally a couple of hours) and gave us an instant feel for how it might work in the app. In the end we decided to not add it to Analog, but we saved several hours by prototyping it on the web rather than coding it in to the app. It’s situations like this where the web wins over native.

Embedded web views are really popular, you might not realise but I bet many of the apps you use on a daily basis have some form of an embedded web view. The Spotify Mac app, for example, has many web views; “What’s New” page, that’s also a web view and so is the activity sidebar.

We’ve embedded quite a few web views in to our apps over the years; the welcome screen for RapidWeaver used to be a web view which used JavaScript calls to talk to the native code.

So there’s certainly an argument for using web technologies in native apps, I just think you have to pick and choose very carefully so as not diminish the experience of your app.

Future wise I can see prototyping using web technologies becoming a bigger part of our work flow. I can also see, within the next couple of years, more apps adding features programmed using web technologies, especially with all the new shiny features currently being worked on like CSS Filters, HTML5 Fullscreen API and the FileSystem API amongst others. You can also get a glimpse of the future with the amazing HTML demos on the Form Follows Function site. It’s certainly an exciting time to be a web developer!

I’d love to hear how you prototype features in your apps or if you’ve written a web based native app, and how it went. Leave a comment below or tweet me @bencounsell.

We’ve been fortunate enough to have our apps featured a few times on both App Stores, and we often get friends and developers asking us what our secret is. Unfortunately there’s no secret or shortcuts to getting featured but then you probably knew that already, right?

It’s worth understanding that Apple doesn’t feature apps to help us developers, it features apps because they benefit Apple and its customers - as long as you remember that, you’ll do just fine.

That said, there’s a number of things that people often overlook that we feel can improve your odds. So here’s my shortlist of things that you can do to increase the chances of getting your next app featured.

1. Build a Great App

I know this is obvious and much easier said than done, but it really is the most important thing to keep in mind. If you’re building an app to try and make a quick buck you’re not going to get featured. If you’re passionate about building great apps and shipping something you’re proud of, the chances of being featured are much greater. Sooner or later Apple will take notice of you - consistency is the key here!

If you look at it from Apple’s perspective, Apple only want to highlight apps that show off how great the Mac and iOS platforms really are. They certainly don’t feature apps as a favour to developers — again, they do it because it benefits Apple.

2. Target the “Latest And Greatest”

Going to WWDC (or just watching the videos) is a great way to find out what new APIs are in the next OS release and what Apple’s focus over the next year is going to be. This will give you invaluable insight into what you should be supporting in your app.

One example of an API that you should be looking to adopt is iCloud. This is a major strategy for Apple and I believe iCloud is going to be key to the company’s long-term success. If there’s a place for iCloud in your app and you’re not using it, now is the time to adopt it!

Remember it’s in Apple’s interest to highlight apps that show off the latest OS and hardware releases as that drives adoption of those technologies and devices – it all comes back to doing what benefits Apple.

3. Make it Universal

Providing it makes sense (and it doesn’t always) your app should be available on Mac, iPhone and iPad. By doing this you have a much better chance of being featured - here’s why. Imagine this scenario; Apple are looking at putting together a feature on productivity apps, they have literally hundreds to pick from. Are they going to pick the one that’s available on Android and iPhone - or are they going to pick one that’s a universal iOS app, uses iCloud and is available on the Mac too?

If I were Apple I know which one I’d pick.

4. Invest in good UI & UX

Competition in the App Store is absolutely insane, you’re now competing with huge companies that have endless resources and world class teams at their disposal. Chances are you’re going to need to step up your game!

It’s increasingly rare for one-man development shops to get featured on the iOS App Store these days, but if there’s one thing that I’d advise it would be to reach out and hire the most talented UI/UX designer you can afford.

If you don’t have the funds to hire someone full-time, then Dribbble is a great place to find new and upcoming designers who might be happy to team up with you to work on the next big thing.

5. Get Media Coverage

This is pretty tough to do but is absolutely essential for a successful launch. I know it sounds obvious, but it’s crazy how many app developers leave it to the last minute or plan to do it after they ship.

Ideally you should be trying to build some hype to get bloggers and tech sites talking about your app before it launches. I’d suggest putting up a teaser page that includes a promo video or at the very least some screenshots and information about what your app does and when you plan to release it — teaser pages that have little or no information about the app are pretty much useless.

You will also need to make sure you have an email sign-up form and all the usual social buttons on the page to help you build up a following of people interested in the app. A timely announcement when you launch will help propel you up the App Store charts, giving you some much needed visibility and increasing the chances that the right people at Apple will take notice.

You should’t start teasing your app too early - A couple of weeks is generally about right. Any longer than that and you run the risk of people getting frustrated or worse still, a competitor stealing your idea and launching before you.

One More Thing…

Keep in mind that Apple get almost 1,000 app submissions a day, and the small team in charge of reviewing them may just simply miss your little gem of an app due to the huge amount of drivel that gets submitted everyday.

To make sure Apple know about you and your app you should try getting in touch with someone at Apple. I know they sometimes seem like a walled garden, but if you genuinely have a good app, Apple want to know about it.

How do you get in contact with Apple? I’d recommend going to WWDC, chatting with Apple developers after the sessions and in the Labs, submitting Radar Bug Reports and generally networking with your peers as much as possible. Apple will also reach out to developers who pop up on their radar, making your marketing efforts even more important!

There are over 750,000 apps in the App Store, so the chances of getting featured are pretty slim. The good news, however, is you can still have a successful app even without ever getting featured. It’s not a make or break deal, it’s just the icing on the cake.

Good Luck!

As part of a series of posts going behind the scenes here at Realmac HQ, I’m going to be introducing a topic that’s often seen as the black box of software development, QA.

I’ll be featuring more specific aspects of my role in a mini-series of QA related posts while this article will give you a little introduction to my overall role, I hope!

As Quality Assurance manager, I’m responsible for overseeing all things quality related; that means both Quality Assurance and Quality Control. As the line between these two areas can be blurry at the best of times, we often use the term ‘QA’ to loosely encompass both roles. That makes QA a a pretty wide ranging subject that would be challenging to detail what my role covers, if asked to, in a single sentence.

Some of the key areas that I’m involved in day-to-day include writing test and support documentation, issue tracking and, of course, testing all of our apps to ensure they are reliable. One of my overall aims is to ensure the apps we ship are not only bug free and a joy to use, but also that the means by which we build them are the best they can possibly be. I love asking questions as to why things are the way they are. Asking questions is a great way to begin improving something. Why is it that some parts of an app’s development cycle take longer than others? Why is it that one framework or API is particularly error-prone compared to another. If there’s no justifiable reason for something, should it be there in the first place?

Although QA covers the entire development cycle, I personally am not always directly involved at the beginning of an app’s development cycle. For instance, low-level code testing is handled by the project engineers, who independently peer review the code. The analysis of such tests are available to be fully explained and justified to the non-engineering team members. I tend to be more heavily involved once a general feature-set has been settled and when early prototypes become slightly more stable internal releases. At this point I set about forming more detailed test documentation in preparation for more user-based testing.

From the outside, documentation and testing may sound like fairly dry subjects but I like to think a sense of humour plays an important part in good testing. I take great pleasure in throwing the documented processes to the side to deliberately create scenarios that may throw up unexpected behaviours and edge cases in an app. This is an area where human ingenuity can truly trump more rigid automated testing!

When it comes to creating test plans and manifests, I treat each project independently and don’t force them to conform to any processes used in another. However, one useful set of guidelines that I highly suggest you look to base any potential support or issue ticketing process on are Apple’s Bug Reporting Best Practices. The more relevant and detailed information you can provide in a ticket, the more likely an engineer will be able to diagnose and resolve an issue or accurately implement a feature request.

A commonly used word at Realmac HQ is “detail”. We pride ourselves on getting the smallest details right in everything we do from handling errors at code level to designing for retina user interfaces. It’s important to point out that detail doesn’t need to be associated purely with visuals - as QA Manager, I like to think that the details are the individual steps taken to build and ship an app that will delight our users.

Apple released a recruitment video last year that got a lot of coverage online. The video is littered with statements that ring true to anyone who strives to achieve process perfection. The overriding tone of the video was that the focus was not solely on the quality of the end product but really about having the right processes and people in place to enable them to go on and create the best products.

Infinite Potential

The poster above hangs on the wall across from my desk. It reads: “The infinite potential of every little bit”. To cut a potentially long story short, if someone ever was to ask me to encapsulate the mindset and reasoning behind QA at Realmac in a single sentence, I’d point them to this poster.

If there happens to be a topic mentioned here that you’d like expanded upon in my next post, please feel free to comment below or reach me @hamishmcneill on Twitter with any questions.

Earlier this year we started discussing our longer-term plans for OS X support in our flagship app, RapidWeaver. It’s something we’ve given a lot of thought to, and it was particularly interesting to see the feedback from discussions with the users who drop by the RapidWeaver forums.

During our planning for RapidWeaver 5 way back in the summer of 2010, we heard from a lot of people that support for OS X 10.5.8 Leopard was a massively important thing for them. Our stats for OS usage in RapidWeaver (more on that in a bit) supported the case too. The numbers were going down of course, but there was a substantial number of customers particularly in education, who heavily relied on Leopard. So we decided to support Leopard - and still do in RapidWeaver 5.3.1, even on PowerPC systems!

In the intervening years, OS X has undergone a massive overhaul. PowerPC hardware went bye-bye, and then Apple phased out support for building PowerPC apps. Xcode 3.2.6’s default build architecture was “Intel-only”, and Xcode 4 removed support for PowerPC entirely.

If you hadn't realised it, over the last few years Apple’s ability to continually push new technologies has intensified to near-dizzying speed. From an almost-leisurely 18-month+ cycle between OS X releases, we’ve got annual releases of iOS now being feature-paired with annual releases of OS X. The tools we use are being built to support only the newer OSes and given the pace of OS updates and the significant change to our toolset, that obviously affects all developers - especially small teams such as ours!

Given that there’s no user-friendly way to specify which point-release versions of OS X an app supports (i.e. “supports 10.6.8, and 10.7.4+ but not 10.7.0 - 10.7.3”) the minimum OS requirement of your app then becomes incredibly important. So today I thought I’d talk a little about the thought process for our apps as we’ve been doing a fair bit of thinking about this stuff of late.

So What Do We Support Currently?

Our app lineup is interesting to look at, in terms of OS X support.

As you can see, there’s a definite trend! I’ve noted our support for PowerPC versions of OS X 10.5.8, as we treat that a separate OS release that we QA alongside the Intel variant.

So what do we consider, when deciding which versions of OS X to support?

What’s Everyone Using?

Our non-Mac App Store versions of LittleSnapper and RapidWeaver 5 have, since their respective launch, had the option to send anonymous information such as OS X version to us. To show you how we’ve seen OS X adoption skyrocket, here’s some hard data! If you’re wanting to see some more graphs, the folks at the Omni Group also publish their opt-in data. Before you check our data, I should disclaim it:

• these figures are only indicative and from a sub-set of users who have opted to share them anonymously with us;
• the numbers are not from the Mac App Store versions of the apps (however, the Mac App Store requires OS X 10.6.6+, and we consider Mac App Store customers to be more likely to update to newer OS X versions);
• there's potential bias, in so much as we consider people who update their version of OS X to be more likely to check for updates (which is when the information is sent to us).
• Because of the massive skewing of the data in launch month (lots of software update checks) we look at 3-monthly data. So, the stats below are for the period from two months before a major OS X release through to one month after it.

With the App Store making OS X updates even easier, and uptake of new OS releases quicker than ever, there’s certainly an argument to be made that developers should be targeting the newest OS releases. But that’s not the only thing to consider, of course.

Technical Restrictions

Sometimes there’s a technology so critical (or non-optional), that it effectively determines the minimum OS version. One such example is sandboxing on OS X, which has been constantly added to and improved. Sandboxing arrived in OS X Lion 10.7.0, but it wasn’t until OS X 10.7.4 that the sandbox matured enough for us to start adopting it - and as we gradually roll out sandboxing to all our apps, we’ll have to raise the system requirements to ensure we can reliably offer a great user experience.

OS X Feature Adoption

So after we’ve figured out where we have to set the system requirements, we get to the more subjective matter: which OS X technologies determine OS support - and is the developer feature mature enough.

Depending on the scale of the feature involved, sometimes a feature can determine the version we need. It’s not always the case, and sometimes we’ll progressively enhance our apps depending on the OS X version. For the next major upgrade to RapidWeaver, that’s likely to be what we do: offering specific features to a particular version of the operating system but still supporting an earlier version of the OS.

For Clear, whilst iCloud was available in OS X Lion it wasn’t until Mountain Lion that things settled down behind the scenes. Given the extra developer features and maturity of iCloud in OS X 10.8.2 which includes the improvements also found in iOS 6, we felt that this was the best version to target - and it seems we’re not the only ones to come to this conclusion!

Commercial Considerations

Knowing who to support, and the demographic you’re targeting is incredibly important. There will, depending on the scope of the app, be times where longer-term OS support is required - and if you’re supporting apps using iOS 3.x or iOS 4.x you’re probably running into issues that we face supporting OS X Leopard. They’re not insurmountable problems, but they’re definitely something to evaluate and plan for: the longer QA and development is something you’ll have to consider for every changeset and release, not to mention the speed at which you can adopt new features.

Decision Time!

So what’s the right choice? Unfortunately there isn’t one. Deciding the OS support obviously depends on what you’re building, who you’re building it for, and what makes sense from a technical and product marketing standpoint. Here at Realmac we want to offer (and are expected to offer) the latest technologies to the people who use our apps - and treading the line between cutting edge, supporting older systems and the experience our apps offer is a fine art! Our plans tend to be either:

1. Latest-only: When we launch any new apps in future, it’s highly likely this is the path we will take. Given that we’ll be under 12 months away from the next OS release, we want to be in a position to quickly iterate. Caveats are the potential lack of API maturity, and less widespread adoption, however a much smaller number of target OSes makes it easier to iterate the codebase and adopt new technologies.

2. Latest-minus-one: For example OS X Mountain Lion, and OS X Lion. This treads a better balance in terms of installed base - and depending on the versions you support, there’s pairs of releases that work pretty well together (10.5/6, 10.7/8). Obvious caveats however include the possibility of substantial changes between two releases for technologies that (for the end user) are perceived to be identical - again, iCloud for example.

As you can tell, there’s no right (or particularly easy) answer. There’s ways to support older OS versions if you absolutely have to, but it comes at the expense of a less modern and more convoluted codebase which may hamper your plans to iterate quickly. If longer-term OS support is required (either contractually, or philosophically) be sure to budget for the time needed to fully support these versions of iOS or OS X - but at the same time, be pragmatic about what you do support!

If you’ve got any thoughts, I’d love to hear them in the comments below - or just give me a shout on Twitter: I’m @nikf.

Today we’re excited to announce something a little different, something we’ve been working on in conjunction with our friends at Impending.

Your iPhone is the perfect home for a pet, and Hatch happens to be that pet. The adorable, mystical Fugu creature is your loyal companion and goes everywhere with you. Starting today, you can put your name down to adopt your very own, special coloured, Fugu egg which will be hatching in early 2013! In case you need persuading, here’s one Realmac-coloured Fugu which we’ve adopted here at the office.

We’ve been itching to tell you all about Hatch, and hope you’ll check out the teaser video and sign up to adopt your own Fugu too!