GoPro tumbles on Apple sports camera patent news

Shares of GoPro Inc. GPRO, -0.38% skidded on Tuesday, at one point tripping a Nasdaq short sale circuit breaker. The selloff was sparked by news that Apple Inc. AAPL, -1.02% was granted a patent for a sports camera, according to Seeking Alpha. GoPro shares fell 8.5% to $51.98 in recent trading with the stock shedding 15% so far this week.

That a patent can cause such reaction in the stock market says a lot about how the system is volatile and fragile to short term effects.

I'm a big fan of both companies and their products, and, assuming this ever gets to be a real product, I'd love to see Apple's take on a sports camera. It's not only the camera, though. GoPro has built all sorts of accessories to work with different sports. And, while it is priced as a consumer device, it's really professional quality stuff. It's used in the most extreme conditions in surfing spots with the largest and heaviest waves, and it delivers. GoPro also has a strong brand among athletes and sportsy types that most geeks probably don't appreciate. Apple for one knows the value such a brand carries.

I believe Apple will have to show a lot more before there's reason to doom GoPro entirely.

Timeline Algorithms

Brent Simmons writing about Timeline Algorithms

These days, were I writing an RSS reader (I’m not), I think I’d skip developing an algorithm based on the user’s attention — instead, I’d focus on making it really easy to filter out the things you don’t care about, and to highlight the things you’re more likely to want to see.

I think the problem with Facebook's (and soon Twitter's) approach, isn't the algorithm based timeline itself, but the fact that it is effectively the only option.

I've been thinking a lot about that lately. Were I writing an RSS Reader (I might be), I think I'd give it a go. That wouldn't be the only way of reading in the app though. By all means, the user would have the option to see the unfiltered queue. That option would be at least as prominent as the automatically filtered queue and the app would never try to force the user into using the filtered version. Under these constraints, I believe a filtered queue that takes into account past user behavior may be useful in suggesting what to read next.

A new thing

This friday was my last day at PorQueNão?. I had a wonderful year there, in all certainty the best so far in my career. I was given an opportunity that I had been pursuing for a long time, and I'll be always grateful for that. I had the chance to work with great, amazingly talented people there and learned a lot from them.

I'm now an iOS developer at kontent, a UK based startup with a great product that aims to aid quality content discovery in a world full of noise. They have a unique taking on link sharing and I'm very excited to participate on making this vision come to fruition.

Kontent is available on the App Store. The app has been developed so far by Ben Dodson, with whom I'll be working with in the coming weeks on iterating on the app.

Here's to a new thing!

Apple Watch Unveiled

As most of us expected, we had a One more thing moment in today's event. The Apple Watch was announced, and it will ship in early 2015.

The Watch looks stunning. Lots of options, with two different sizes, 3 different lines and many, many straps. If it catches on, it will be a massive money maker.

I find myself wanting one. I don't think it is a no brainer like the iPhone though. When it was first announced by Steve Jobs, even though there were a number of skeptics, it was clear to me that everyone would eventually want it, or at least a smartphone of some kind that would be heavily influenced by it.

The value of the watch today might not be as clear, but I'd bet in its favor for sure. This is just the first iteration, and we're likely to see a substantial improvement in its second version.

Apple showed it doing lots of different stuff. Some might be useful, some might be pointless, but the focus today was in the experience and the possibilities, not on specific features or use cases.

I'm not sure yet what it is that draws me to it, but I do want it.

A Candid Look at Unread’s First Year

Shortly after publishing my last piece, which one could say is rather optimistic regarding the future of indie development, I came across this post by Jared Sinclair

Unread for iPhone has earned a total of $32K in App Store sales. Unread for iPad has earned $10K. After subtracting 40 percent in self-employment taxes and $350/month for health care premiums (times 12 months), the actual take-home pay from the combined sales of both apps is:

$21,000, or $1,750/month

Considering the enormous amount of effort I have put into these apps over the past year, that’s a depressing figure. I try not to think about the salary I could earn if I worked for another company, with my skills and qualifications. It’s also a solid piece of evidence that shows that paid-up-front app sales are not a sustainable way to make money on the App Store.

Unread is a great app. I use it every day. Jarred's honesty and transparency are a great service to the community. It's saddening to hear the app isn't generating enough cash to compensate for the effort he put in it.

Anyway, maybe I'm just naive, but I still maintain everything I wrote in my previous post.

The New Indie

I haven’t been part of the iOS development industry for long. I started dipping my toes in iOS development around the same time I bought my first Mac and iPhone, back in 2009. At the time, I was an Electrical Engineering student with a good job pretty much guaranteed when my graduation came, which happened 2 years later. So, I mostly pursued iOS development as a serious hobby, much like I do with the other stuff I enjoy.

Even though I didn’t commit professionally, I payed attention. I kept up to date as much as I could, managed to do a little freelance work and got two simple apps published, both of which faded out of existence as I mostly neglected them. More importantly, my experience in my full time job in a different (albeit related) field, combined with what I could get under my belt thanks to my on the side efforts were enough for me to get a job as an iOS developer once I decided it was time to go after it. And thankfully, I got a great one. I work from home, I enjoy what I do and I didn’t have to make any sacrifices to make the transition.

However, the holy grail for me is going indie. The issue is I obviously missed the gold rush. In fact, word is out on the street that The Majority Of Today’s App Businesses Are Not Sustainable[1]. From what many successful and experienced people in the industry have been noting for a while, that the times to come aren’t poised to be the best ever[2]. Maybe that should frighten me as a young and mostly inexperienced newcomer, as well as anyone who is thinking of going indie now or in the next couple of years. But, and maybe that’s just my young and careless self talking, it really doesn’t.

I believe the people who were best positioned to succeed in becoming independent during the first years of the iOS App Store were those with a pioneer mindset. The ones who could see the new opportunities first, get in quickly and reap the rewards fast. The bold and brave, if you will. Once they had their first success, they were able to deservedly build on top of it.

I think the new scenario — a more mature and stable market, with a lot more competition — favors a different mindset for those looking to get in, and it is time to shift gears accordingly. Most of the successful new indies in the coming cycle will be those who are able to keep at it by sheer perseverance and diversification, going slow and steady, and committing to the long term. Like in investments, the optimal strategy isn’t putting several eggs in one basket that looks like a great opportunity, and going all in on it.

Of course, this requires not only a different mindset, but also a different set of initial conditions. This approach won’t bring fast rewards. Much like wannabe indie bloggers have to put a few (many) years of work before actually being able to take the plunge, we developers must be willing to accept the same. This requires having the means to support ourselves in the meantime, while making significant sacrifices in other fronts.

There are many indie heroes[3] to look up to and draw lessons and inspiration from, who succeeded early in the App Store game — and continue to do so — or even who have been doing it far before App Stores were a thing. Among those, I think David Smith’s approach is the one which best suggests what the path to becoming an indie in the next cycle will look like. Quoting from his Five Years in the App Store post:

I think the single most significant attribute of my approach to the App Store that has allowed me to do this full time for so long is the number of failures I have. I have shipped somewhere around 80 unique app concepts over the last five years. With the exception of games, I’ve tried almost everything I can think of. With each attempt (in success or failure) I learned something new about what makes an app great.

That’s a lot of apps. So, while I believe the mythical indie is far from dead, I think the path to going indie is a lot less glamorous than what most have come to expect. A beautiful idea followed by a great execution doesn’t necessarily guarantee success. It will take a lot of scars to get to it. If we, however, start seeing numerous people willing to put in David Smith level of commitment and not being able to make it, maybe I’ll be ready to believe the future of indies is grim after all.

We, the aspiring indies, need to keep in mind that being independent is a great privilege. It is a largely unattainable goal for most careers. Software developers should be glad this path is even a possibility. It’s hard. It should be hard. The euphoria of the period behind us has led many to take this possibility for granted, so we feel like anyone who is great at what they do should be able to achieve it. We shouldn’t. Being great is no longer enough. More than anything, we need to be committed. And maybe, just maybe, we will be ready when the next big wave comes.

  1. There is a very obvious question that this piece fails to address. How many of the apps deemed “unsustainable businesses” from the criteria used in the article are actually businesses in the first place?  ↩

  2. Who at the Table is an Indie iOS Developer? and Confessions of an ex-developer are both great pieces that give insight on the matter.  ↩

  3. Brent Simmons, Daniel Jalkut, David Smith, Manton Reece and Marco Arment, just to name a few whose work and words influence me on a daily basis.  ↩

Revisiting Reverse Ranges in Swift

In a previous post, I wrote about working with reverse ranges in Swift. One day after that post was published, Apple released Xcode 6 Beta 4.

Xcode beta 4 added two functions to iterate on ranges with a step other than one: stride(from: to: by:), which is used with exclusive ranges and stride(from: through: by:), which is used with inclusive ranges.

To iterate on a range in reverse order, they can be used as below:

for index in stride(from: 5, to: 1, by: -1) {
//prints 5, 4, 3, 2

for index in stride(from: 5, through: 1, by: -1) {
//prints 5, 4, 3, 2, 1

Note that neither of those is a Range member function. They are global functions that return either a StrideTo or a StrideThrough struct, which are defined differently from the Range struct.

There's still not much to say on this, and the Beta 4 release notes suggest there are still changes on the way to accommodate negative ranges. At least, the weird cases that came up with by() are gone.

Interesting Swift Features

Great post by Mike Ash on some of Swift's interesting features. His explanation of Optional Types is specially good.

The existence of NULL in C (which is the same as nil in Objective-C) means that all pointer types in the language are implicitly optional types. If you have a NSString *, it means "pointer to NSString, or nil". If you have a char *, it means "pointer to char, or NULL".

The existence of NULL in C blows apart the entire static type system when it comes to pointers. Every pointer type is a half truth. Whenever you see a type "pointer to X", there's always an implied "...or NULL."

Working with Reverse Ranges in Swift

Update: Xcode 6 beta 4 brought changes pertaining iterating through ranges. The content below is thus outdate. See this post.

Reverse ranges have a weird behaviour in Swift. For example:

for index in 5..<1 {

The code above results in an infinite loop. That's because the loop starts from 5 and increments at each iteration, never actually reaching 1.

In order to get the expected result of printing the numbers from 5 to 2, one should use the by() member function of the range structure, passing in -1 as the value for the step:

for index in (5..<1).by(-1) {

Note it’s necessary to enclose the range inside parentheses.

However, there’s a catch. Iterating in reverse through the open interval, built with ..<, will yield the expected behaviour, which in the example above is to print the values 5, 4, 3 and 2. However, if the closed range operator - ... - is used, instead of going until 1, the loop will stop at 3. Weird, but that’s because a...b is defined as a..<advance(b,1).

Another option to iterate through a reverse range is to use the ReverseRange() function, which will work as expected for closed ranges:

for index in ReverseRange(range:1...5) {

The code above prints 5, 4, 3, 2 and 1 as expected. However, the same code with an open range operator will print starting from 4, since the reverse of 1..<5 is actually 4...1.

Adapted from my answer on Stack Overflow

Making HTTP Requests in Swift

As I mentioned in a previous post, I've been meaning to write more about programming here. While my initial idea was to set up a separate feed, I'll just post as I normally do and think about it on another occasion.

I'll start with a series of posts on Swift, Apple's new programming language for iOS and OS X development. The first few posts will be based on some of my answers to questions on Stack Overflow. So, without further adue, let us discuss simple HTTP GET Requests in Swift.

The same options available in Objective-C can be used with Swift. I'll only cover those that don't involve using third party libraries such as AFNetworking.

Using NSURLSession

First, initialize an NSURL object and an NSURLSessionDataTask from NSURLSession. Then, run the task with resume().

let url = NSURL(string: "")

let task = NSURLSession.sharedSession().dataTaskWithURL(url) {(data, response, error) in
    println(NSString(data: data, encoding: NSUTF8StringEncoding))


Pretty straightforward. Also, the block syntax in Swift is much more pleasant to read and write, specially when benefiting from trailing blocks, which is possible since the block parameter is the last argument to the NSURLSessionDataTask initializer.

#Using NSURLConnection

First, initialize an NSURL and an NSURLRequest:

let url = NSURL(string: "")
let request = NSURLRequest(URL: url)

Then, you can load the request asynchronously with:

NSURLConnection.sendAsynchronousRequest(request, queue: NSOperationQueue.mainQueue()) {(response, data, error) in
    println(NSString(data: data, encoding: NSUTF8StringEncoding))

Or you can initialize an NSURLConnection:

let connection = NSURLConnection(request: request, delegate:someObject, startImmediately: true)

Just make sure someObject implements the NSURLConnectionDataDelegate protocol, and then deal with the data received in the appropriate delegate methods.

For more detail, check the documentation for the NSURLConnectionDataDelegate protocol

#Testing on an Xcode playground

In order to try this on an Xcode playground, add import XCPlayground to your playground, as well as the following call:


This will allow you to use asynchronous code in playgrounds.

#Final remarks

While I provided code that uses both NSURLSession and NSURLConnection, NSURLSession is the preferred solution. Even though NSURLConnection isn't officially deprecated, this has been stated by Apple engineers on several occasions during WWDC sessions.

Finally, here's a gist with the NSURLSession based implementation.

Adapted from my answer on Stack Overflow

On Swift

One of the least expected and most exciting announcements of this WWDC has been Swift - an all new programming language for iOS and OS X development.

There’s been a lot of praise on how Swift is a truly modern language with a friendly syntax, and how it will enable developers to be more productive.

However, as much as Swift is a big deal on the short term, you don’t change[1] a platform’s language just to make things nicer and developers more productive in the present. You do it because it will,in the long run, enable things that weren’t possible before, by allowing for a new way of thinking about problemas and how to solve them. But as nice as it may be, and for as much potential as it might have, a language is only as good as what it enables developers to accomplish. On that front, Swift is off to a very good start.

By being fully compatible with all the same Apple APIs and Frameworks as Objective-C, Swift has a major advantage out of the gate to guarantee its wide adoption. Add it to the fact that it will run on the most popular developer platforms that have ever been around and you get a sure formula for success. That’s precisely why comparisons to the Dylan effort of 20 years ago shouldn’t lead to the conclusion that Swift will have the same fate. The context is very different.

Even though Swift code can coexist peacefully with Objective-C inside the same project and with full interoperability between them, it is free from having to comply to ANSI C standards. It’s effectively free from C’s legacy and doesn’t need to follow conventions established in a context that is 40 years old and may no longer be relevant, necessary, or, generally applicable. This will free developers from dealing with a lot of cruft. Of course, the frameworks are still written in Objective-C, so it will take a long time before they’re able to take advantage of all of Swift’s new features and start being made primarily with Swift in mind.

Swift further confirms what is easily observable for anyone who has a clue about Apple. They’re in it for the long run. Swift’s development and its launch this week wasn’t meant to solve the problems of today. Objective-C wasn’t exactly holding Apple back right now, but it might, someday. While Objective-C and Next’s acquisition, along with Steve Jobs return, saved Apple in the end of the 90s, it’s Swift the programming language which will help power Apple’s future going forward. It will enable Apple to continue fostering innovation within its platforms for the decades to come, while providing an incredible platform for third parties to develop on.

  1. Objective-C isn’t going anywhere, at least in the near future, so Apple hasn’t really changed the language for its platforms. It has added a new possibility, but it’s pretty clear that going forward, Swift will gradually become their platforms’ main language, eventually replacing Objective-C for good. It’s where Apple’s attention is from now on, and where ours as developers should be too.  ↩

After WWDC

WWDC has ended, but the real work starts now. It seems Apple decided this was the year they'd make all of its platform's developers dreams come true. A massive amount of new APIs that not only allow existing apps to get even better, but that enable whole new categories of apps that previously were not possible. On top of that, there's Swift an all new programming language. As such, there's a lot of work to be done, in a good way.

Extensions will bring applications the ability to customise user experiences across iOS and OS X while at the same time collaborating with other apps. Continuity will allow apps to provide their users with the ability to seamlessly transition between devices, taking their current task from one context to another with ease. iCloud drive and document sharing features will bring great data sharing between apps without giving up on the sandboxing model that helps make iOS secure.

But all of this is just the beginning. These are things we've long asked for, and the first wave of improvements to existing apps and new apps will aim at using the new APIs to solve problems we've all had and wanted to tackle for a while. But there is a whole new class of opportunities most of us aren't even aware of right now. The great new apps of the coming years will come from those who see such opportunities and successfully execute on them.

If you've been developing for iOS for a while, but not long enough to have taken part on the early life of the App Store, you may feel you've missed the train. But with what has been announced this week, there are a lot of trains just about to leave their stations right now. There's plenty of time to hop on one of them and reap the benefits.

Loom is joining Dropbox

It’s been a long road and we feel that we have come a long way in solving this problem. We are elated to announce the next step in this journey: Loom is becoming a part of the Dropbox family. We look forward to this transition as the next step in creating a home for all of your photos and videos, seamlessly organized, while still keeping them at your fingertips. With Carousel, Dropbox has created a gallery for your life’s memories. It’s a single home for all your photos and videos, automatically organized and always with you.

A few months ago, I struggled with the choice between Loom and Picture Life. I am glad I picked the latter.

Considering Spotify over Rdio

Spotify finally officially arrived in Brazil[1], and along came a major redesign of the iOS and Mac apps, bringing the long awaited collection feature.

I had tried Spotify before using Unblock-Us, but I couldn’t sign up to the service with a Brazilian credit card. Anyway, having to organize my song collection through the exclusive use of playlists was a major deal breaker, and I had decided to stick to Rdio, even though the Spotify catalogue seemed better suited to my tastes, from my limited experience.

While Spotify’s collection feature is a great addition, which finally makes the service usable for me, it’s still inferior to Rdio’s implementation.

On the Mac, you can view a grid of artists, but once you choose a particular artist, all you get is a list of songs which are sorted by album. Rdio on the other hand offers the possibility to view a more compact list of artists on the side, while offering a grid view of an artist’s albums, which can be toggled to a list view of songs sorted by album.

On iOS, there is no grid view, but the same problems hold. Once you are viewing you album collection, there is no way to filter by artist. If you navigate to an artist, you can only see the list of songs by that artist. There’s no way to see a list of albums.

On the mac, I also find the album covers in the grid view too large. Using the Spotify app on full screen on my 13" Retina Macbook Pro, I can see 4 albums per row. Comparing that to iTunes, which shows 8 albums in a row I find it much easier to browse my collection on iTunes than on Spotify. While Rdio shows only 5 albums per row at most on my laptop screen, it’s not as much of a problem since there’s the ability to filter the album grid by artist, which is what is actually lacking in Spotify.

As a side note, I also enjoy Rdio’s lighter style over Spotify’s predominantly black design.

As to pricing, Spotify is currently cheaper, with its premium plan at $5.99 per month. Rdio’s unlimited plan is currently priced at $9.99 per month.

With all that said, even though I find the Rdio app superior, the choice of services is no longer a no brainer. Spotify’s new collection feature, while lacking in several aspects, is good enough to make me seriously consider it over Rdio. The defining factor is no longer the apps, but the catalogues offered by each service.

  1. The dreadful licensing issues continue to be present, limiting the experience for international users on Spotify, and all similar services. It’s one thing if an artist or label decides not to distribute its content through streaming services at all, or licenses exclusively to a single service. However, regional limitations for availability of specific pieces of content feel artificial and are poisonous to the TV, music and movies industry. It is an artifact of a time before content distribution had the means to be as ubiquitous at it is today. It has to go.  ↩

Xcode Plugins

Xcode has had a plugin architecture going back to when Interface Builder was its own separate app. However, this system was relatively obscure, undocumented, and not widely used by third parties. Despite this, developers like Delisa Mason and Marin Usalj have done incredible work creating a stable and vibrant ecosystem of third-party Xcode extensions.

Simply install Alcatraz, and pull down all of the plugins (and color schemes and templates) that you desire.

Nice list of Xcode add ons.

Don Melton's Memories of Steve Jobs

The room got quiet. Steve and I sat side-by-side in front of the demo machine staring at Safari. Suddenly we turned to each other and said at the same time, “In the page address field!”


Smiles all around. Which I followed with, “I’ll have a working version of that for you by the end of the week.” Over-committing my engineering team, of course.

But I didn’t care. I had just invented something with the Big Guy. True, it was a trifle, but there’s no feeling like sharing even a tiny byline with Steve.

Great, great read. Everything Don Melton writes online should be compulsory reading for every Apple fan. There aren't many sources around for this kind of material, much less with Melton's eloquence and ability to naturally convey his emotion.

Little Big Adventure Review

Touch Arcade has a review of Little Big Adventure, a classic PC game which has been ported to iOS and Android as of last week. The game is currently priced $3.99 both on iOS and Android.

Back in the late nineties, I played through and enjoyed thouroughly the game's sequel, Little Big Adventure 2: Twinsen's Odissey, without having ever played the first one.

Today, I finished the game on my iPad. As one would expect from any port of a title that is 20 years old and relied completely on the keyboard for input, not everything was perfect. On the other hand, it's far superior to most of the iOS "serious" gaming experiences I've had. As such, I take issue with a few parts of the review.

The aim of the game, and how to progress is also extremely unclear. Little Big Adventure is a game where you kind of find your own adventure, and how you opt to tackle obstacles. No arrows show you where to go, and there is no quest log. These are some aspects that would have needed some reworking to accommodate the demands of today´s gamer.

Little Big Adventure is not a casual game. The aim of the game or how to progress is not unclear. It's explained through dialogues with NPCs and interaction with elements of the world. Finding the next step is part of the game due to its highly exploratory nature. If it's difficult to discover what to do next, it's by design and not at all a flaw. It's actually refreshing to play a game that makes the player think, rather than handing instructions for every step on a silver plate.

I remember having direct control over Twinsen on my PC using arrow keys for movement. On iOS the movement is indirect with you touching where you want Twinsen to go. This would be a suitable control method if Twinsen had any intelligent way to avoid obstacles. If something is in the way he simply walks, or runs into it. When just exploring this is a minor annoyance, but as soon as you are trying to escape an enemy it almost breaks the game. It tears on patience though, and having to restart in the asylum being caught by the fascist elephant guards is truly testing my patience.

I'll concede that the controls are not ideal. But the port made a good job adapting them to what would be possible on a touchscreen - far better than slapping a virtual joystick with virtual buttons and calling it a day. Whether this is enough, is a matter of opinion.

Porting a classic isn’t all that easy to do, and sometimes it might be better to ponder remixing or at least remastering the original material. Little Big Adventure is a clear example of this where some core elements such as controls, lack of direction and confusion to when the game saves make it less than ideal for mobile gaming. Personally I really wanted to fall in love with Little Big Adventure again some twenty years after our first affair. Sadly it has aged even worse than me, and not even nostalgia can get me past that. It is a true shame, as beyond the problems there is a terrific genre defining adventure to be found.

What is ideal for mobile gaming? What is mobile gaming? Is it playing on a line while looking up every 10 seconds? Is every game that is adequate to a mobile platform necessarily a casual game?

I sure hope not. I enjoy playing Cut the Rope while waiting for coffee, but when I sit on the couch at home to play games on my iPad, I want as much of an immersive experience as a game like Little Big Adventure can offer. The nostalgia surely contributed to making this particular game so enjoyable. But I hope a mildly negative review as the one linked here won't stop gamers who never had the opportunity to accompany Twinsen on his adventures from enjoying this wonderful game.