If you’ve ever found yourself needing to send one of your lists in Clear to a friend or co-worker, you’re going to love the latest update to Clear for iPhone and Mac.

The ability to Email lists is a feature we’ve received a lot of requests for, and we’re really excited to launch it today! To send your list, just shake your phone to bring up a handy email option, or if you’re using Clear for Mac you can find it in the Actions Menu. The email contains both your list and a file that allows the list to be opened in Clear!

If you’ve not yet picked up a copy of Clear, check it out on the App Store for iPhone and Mac.

We’ve got lots more in the pipeline for Clear, including some of the other most requested features. But for now, stay focused and keep Clear!

Last week we announced Analog Camera for iOS, and so far the reception has been pretty overwhelming, the announcement got picked up by the likes of TechCrunch, TUAW, AppShopper, iMore, Forbes, MacLife, and many, many more.

We released a very short (12 seconds to be exact) video giving a brief glimpse of what to expect and so far it's received almost 70,000 views! If you've yet to see it, take a peek below:

Analog Camera for iPhone is due out later this month. You can follow @analogcamera on twitter or sign up to our newsletter to be one of the first to know when Analog Camera goes live!

I keep reading blog posts and tweets that insist you can build web apps that look & feel as good as native apps, but I’m not convinced you can.

The debate on Native vs Web apps has raged for years, but came to the fore after the iPhone was released in 2007. There was no Native SDK, you couldn’t build apps for the iPhone! But wait, the iPhone shipped with a fully fledged Web browser.

You’ve got everything you need if you know how to write apps using the most modern web standards to write amazing apps for the iPhone today

Steve Jobs, iPhone announcement 2007.

You can take that with a pinch of salt, but I still believe Jobs thought apps based on web technologies was a viable option.

Zoom a year forward to 2008 and Apple released the iPhone SDK. Native apps start getting built, the App Store launches and the rest, as they say, is history.

Why didn’t Web apps take off?

Web based apps had an entire year’s head start on native, they had (have) no app store restrictions (submission times, rules, rejections, etc), but we didn't see any web apps really take off.

So why didn't that happen? The simple answer, in my opinion, is that the technologies were’t up to scratch. The JavaScript rendering engine was slow, CSS support was good but any animations were laggy and you didn't have access to important hardware features such as the camera or GPS signal.

Another reason was the development tools just weren’t (and arguably still aren’t) available.

I still believe some of these issues hold true today, and as I noted in my last post:

Facebook recently re-wrote their iPhone app to be native due to performance issues with the HTML version.

If a company the size of Facebook, with the resources they have and the enormous pool of talent they’ve hired/acquired, can’t build a web app that matches native performance then I’m not sure who can.

What actually got me thinking about all this was a post over on Forecast’s blog: It’s not a web app, it’s an app you install from the web

Navtive vs Web weather app

Forecast is one of the best apps built using web technologies available today. It looks great, all the animations are smooth and everything is responsive. The Forecast team did a great job.

Their post is full of useful tips and helpful info on building web based apps, but one thing caught my attention:

If you can’t find a way to do something that doesn’t feel choppy or awkward, then just don’t do it. Design your interface around the technology you have, not the technology you wish you had.

I think this is where their argument that web apps are capable of being as good as native, trips up.

If you can’t find a way to do something using Web technologies, but you can do that thing using native, then “just don’t do it” doesn’t cut the mustard when your aim is to build true next generation apps.

The reason why every app that blows you away is native is because the development tools are available, the technologies are standardised across devices, and most important they work as expected. Today. Sadly, that’s just not the case with the web.

Another post, by Bruce Lawson, that I encourage you to read is What does the web platform need?

The advancement of what marketing and the press like to call “HTML5? (but mostly isn’t just HTML5) is closing the gap between the capabilities of native and web. But it isn’t there yet.

Bruce has created a gist asking developers why they choose native over web, some of the common reasons listed:

• DRM
• Geolocation in the browser stops tracking when screen goes blank
• Hardware access (camera, GPS, NFC etc)
• UI fluidity
• Developer tools

The list goes on.

As a web developer it pains me to write posts like this — I really want to be able to develop world class apps using Web technologies — but we’re kidding ourselves if we think web technologies can create fully fledged, next generation apps today.

I believe in the web (I develop for it after all!) and the potential and real advantages it has over native, so my hope is that within the next months and years we’ll see better support and access to device hardware and system APIs, giving web developers the ability to write those next generation apps.

The only way to do that is to create apps with web technologies that push the boundaries of what's possible today. We should be reporting bugs, requesting features, getting involved in specification discussions and generally evangelise the web. That's what I plan to do.

When the company was much younger, we used to pre-announce releases with a fair amount of notice. As with any project, best laid plans get changed, and release dates get missed.

Recently we’ve been a lot more disciplined in how we plan our releases. It’s a popular myth that apps are “easy” to make and I thought I’d talk about the compromises and decisions we have to make every day when building apps.

So there’s this thing called the Iron Triangle. It’s been slightly adapted and tweaked for software development over the years, but basically the saying goes that there are three variables to keep in mind while developing an app:

1. Date (Shipping Date).
2. Features (Capabilities, what the app can do).
3. Quality (UI/UX/Code).

Sounds reasonable. But here’s the catch, in reality you can only ever really prioritise two out of the three attributes. Here’s a typical diagram showing what an Iron Triangle looks like. Pretty boring, huh?

Here’s an example of how it might work during a project. Imagine you’re halfway through development of an app and you decide to add a new feature, albeit a small one. By doing this one of the other variables will have to give. You can ship on time with a slightly less polished app, or keep the quality up and ship later than planned. These seemingly little changes can happen countless times during a project and as the changes stack up things can get out of control very quickly. That shipping date you originally planned for just keeps getting further and further away.

Now lets look at a real world example. With Clear for iPhone we made the decision to choose date and quality. We wanted to ship a polished app (that’s always our main goal), but not spend a year on it as we wanted test the waters on iOS. Cutting back on features was the obvious choice although not an easy decision. By doing this we managed to ship a high quality app in a very short space of time. So Clear for iOS easily fits within the rules of the iron triangle.

Perhaps it’s better visualised as an isosceles triangle, instead of an equilateral triangle. Mainly due to the fact that we give more weight to two out of the three attributes.

Unfortunately projects don’t always go to plan… We’re now wrapping up development on one of our other yet to be released iOS apps. As with Clear we decided to focus on time and quality, build an app that is super focused, has a great experience and only has the features that really matter. Everything looked good on paper so we set aside around 3-4 months to build it. During development things changed. Features were added, the UI was tweaked, the user flow re-worked many times, In-App Purchase (IAP) was added then removed and many other little decisions were made along the way. All these changes happened because we care deeply about the products we ship, we care about keeping the quality up, about building something that feels just right.

So where does that leave us? I’m really not sure to be honest. But whatever the shape of the project, the takeaway from this is to use the iron triangle as a reminder of how every little decision you make along the way affects all other aspects of the project more than you might realise.

We’ll be taking the wraps off our next iOS app in the coming weeks - follow @realmacsoftware to be the first to know when it hits.

Continuing a series of posts on all things ‘QA’ here at Realmac HQ, I’ll be sharing a little about how we like to make the most of our issue tracker, as well as using the tickets logged within it to efficiently create detailed test plans.

Tuning Tickets

If you’re not already using a system to keep track of bugs, I highly recommend looking at a service like Lighthouse, a system in which we also manage projects in - far from using it as just a bug tracker. We sweat the details to ensure we ship great apps - we also place great value on being efficient behind the scenes too. Playing down the value of getting the most out an issue tracker could cost a lot of time that would otherwise be better spent crafting the actual app!

Within an ideal ticket, duplicate bug reports are avoided, concise steps to reproduce a bug are detailed by the first person to experience the issue, and explicit explanation of expected behaviours for new features should always be present. Of course, that is the ‘ideal’. It’s also important to tune and refine the ticketing process, striking the right balance between getting enough pertinent information before taking up too much of the bug raiser’s time.

We’re currently using a fairly common template to log bugs within Lighthouse (based on Apple's own bug reporting best practises) where we request a few specific fields of information that’s used to look at how and why a bug is present.

We could request much more information by default but, as mentioned, it’s vital that logging a bug doesn’t become a chore - keep the process quick! For example, have you ever used an app, particularly during a beta phase, and come across a seemingly obvious bug and thought “the developer must know about this already, I won’t waste the time taken to log it when it’ll probably be a duplicate.”? If the bug wasn’t already noted as being a known issue in the app’s release notes it probably hasn’t been raised yet. It’s natural to zone in on particular areas when working on projects but failing to step back to view the app as a whole poses a risk of missing a bug that, perhaps, would have been seen after stepping back from the project.

If I weren’t in a position where time can be dedicated specifically to testing, I’d want to ensure that any ad-hoc or beta testers are made aware of the fastest path to raise a bug, so that even the small or apparently obvious bugs may still be reported, avoiding leaving it to chance at being picked up. Providing clear steps on how best to raise an issue within release notes will help encourage a higher response rate.

Of course, this process can be made even more straightforward by making use of the extremely useful HockeyApp where app crash reports are automatically collated from an app, whether or not they’re in beta or the App Store. We’ve recently integrated Lighthouse, our bug tracker, into HockeyApp to allow for quickly creating tickets which automatically include all the information gathered and organised from within HockeyApp.

Fast-Track Test Docs

For every ticket raised in Lighthouse, be it for a bug, feature, view or behaviour in an app, I add a test case to a test plan that’s specific to that particular app or project. I find that by using the existing tickets from within Lighthouse, I can fast-track the addition of new test cases to a test plan, to both save time writing them from scratch as well as ensuring as much of that app as possible will be tested.

As mentioned previously, the Lighthouse tickets I use as a starting point for a test plan should already include the required input (steps, files or gestures) to perform an action as well as the expected output i.e. the resulting behaviour from our input. Likewise, with bugs found during development, tickets should also contain steps to reproduce the issue as well as any other anomalies to look out for when testing. This is essentially the core information that makes up each test case.

As new tickets are assigned over to Quality Control I check the ticket and create the new test case within a test plan, had a prior test case for the issue not existed. Our test plans are hosted on a private Wiki here at Realmac HQ (you can find out a little more about our network setup, including the Wiki, in this post by Keith).

Unique ticket IDs that link directly from the test plan back to the Lighthouse ticket are also added to each test case. This makes checking for regressions much more efficient as I can quickly check the build number of an app where a reoccurring issue was fixed previously. Integrating commits from Beanstalk within tickets means, in theory, it’s possible to pinpoint the code responsible for a bug within seconds. This, coupled with the inclusion of ticket IDs in release notes, saves time previously taken up by inadvertently creating duplicate tickets.

I’ve recently been looking at further ways to create effective test documentation. For example, creating visual flow-documents for some of our apps, where every view and the connections between them are laid out. As well as flow-docs, I’ve looked at MindMapping, a great way to check that there’s no areas left unchecked within a test plan. A nice example of an iOS testing MindMap can be found here, created by @noir and @lelchuk.

An Evolving Process

Everything can always be improved in some way, especially in QA. More detailed test cases can be created and added to a test plan, new bugs will always be found. That’s a fact that can take time to get used to. In his recent post on the human impact of bugs, @jury sums this up well:

“Realistically, we are never going to fix all of the bugs in our software. Anyone who tells you they don’t ship until all the bugs are fixed is either lying or naive.”

Not only is the fixing of the little bugs a never-ending process, but so too is the refinement and evolution of all the steps it takes behind the scenes to design, build and ship great apps!

Open Q(&)A

At a time where engineering and design focussed resources and articles are readily available for Mac and iOS development, there’s plenty of room for more open discussion on QA. So if you’ve got any thoughts, comments or questions on anything I’ve mentioned above, I’d love to hear them! I’m @hamishmcneill on Twitter.