Archive for Apple

A Swift Softening

enter image description here Listeners to last week’s Coder Radio know that during the live feed WWDC coverage, I was less than enthused with the announcement of Swift, Apple’s new programming language for iOS and OS X. My initial reaction was based on the somewhat unclear way they announced Swift; it was not very clear what they wanted us developers to use Swift for and that led me to the wrong conclusion that Swift is designed to be a near to medium term 100% replacement for Objective-C – this simply is not the case. So far, I’ve read through the Swift book on iBooks and the documentation publicly available twice and found something very surprising – Swift reminds of QML in QT.

This might sound a bit odd, given that in a lot of significant ways Swift and QML are very different languages, but they actually share a kindred spirit and will likely take the same place in my tool-chain – layouts. Yes, both Swift and QML are technically capable of so much more than layouts but really they are both well suited for that task in particular. Why do you think the WWDC demo was so UI / visuals heavy?

So the bottom line is no I don’t hate Swift and no I don’t think it will be the end of Apple development as we know it. And yes, I will be using it but, at least for the next year or so, in the same capacity as QML and its relationship with Objective-C will be same as QML’s with C++ in my QT code-bases.

Questions? Comments? Find me on Twitter.

WWDC 2014 Predictions

WWDC 2014

Well, it is that time of year again – when the tech space goes crazy with Apple fever and starts to have dancing iTVs and iWatches in their heads. From the Apple developer perspective, this is (like the WWDC of 2012) being preceded by increasing frustrations from the community regarding Apple’s tools but more their practices – these complaints have been grumbling under the surface and indeed I’ve been at the forefront of sounding the alarm, but some fights have already been lost and if history is any indicator the prominent Apple devs will be placated by pretty much whatever they get on Monday. Still, to be fair, if Apple could address a few core areas of developer pain, then there would be legitimate cause to celebrate.

Contracts / Intents: Windows Phone and Android both have viable solutions to interapp communication that work very well for the developer communities on those platforms, the platform vendors, and of course the end user. iOS, however, has no real solution to this problem; I don’t consider and a reasonable person would probably agree that the current URL schemes tricks are all just really sloppy hacks that should never be shipped and no sane developer would use them by choice if there were a better alternative. There is no technical reason that this can’t be done and at this point Apple’s stubbornness is doing a huge disservice to the developer community and the end user.

App Test Distribution: One of the most annoying aspects of being an Apple developer is that whenever a customer or even a teammate gets a new iOS device, we have to go through the whole rigmarole of getting the devices UUID, adding the UUID to our developer portal, regenerating a provisioning profile, and making making a whole new binary just to get that one new device into the testing pool. This is absurd. Apple for good reasons wants to limit how apps are distributed outside of the App Store but at this point, there system is too much of an inconvenience to developers (a group I strongly feel is important to their long-term success) to be tolerated one day longer. There is some hope – a few months ago Apple purchased Testflight and that suggests that they intend to streamline the test distribution system.

Mac Mini Refresh: I’ve been careful not to put oo many consumer / new product requests in these sort of posts but I am willing to make an exception for the Mac Mini. Though the mini is probably the least sexy device that Apple sells, it is extremely important for the developer community at large, as a ton of little shops are almost 100% Mac Mini shops. At this point, it is pretty hard to justify the purchase of a Mini given how old the tech in the device is and the somewhat poor value proposition – at least compared with the iMac or an equivalent Windows PC.

That’s it. I don’t think these items are too crazy but am not so sure that we are going see anything of significance in any of these areas. My guess is that we will see nothing the way of interapp communication, a half step toward an easier test distribution, and little more than a spec bump or price drop on the Mini.

If you want to troll me when I inevitably proven wrong on Monday, then please follow me on Twitter.

2014 Predictions

I hope that you have all had an awesome New Year’s Eve! I’ve decided that I’ll start off 2014 by making a fool of myself by trying to make some predictions for the tech industry for the new year. This is not a what you will see list, but nor is it a what you won’t see one; in reality, I am trying to focus more on trends than anything else. Overall, 2014 is looking to be a transition year rather than a real game-changer. This is in no way a bad thing and makes sense for where we are in what is usually a twenty year tech cycle; it is important to remember that the mobile revolution is not even half way done and there are still a lot of incremental advancements that need to be made in that area before it can be considered complete. Still, this article will not focus on mobile exclusively but will rather jump around with no other aim than what I find interesting.

Docker: Docker is the darling of the developer community right now and for good reason — it solves a problem that (outside of the BSD community) hasn’t really been properly addressed. There is however a risk of certain segments of the community drinking a little too much of the Koop-Aide and using Docker in ways that it wasn’t intended to be used; just think about what we saw with Rails a few years ago and the hype surrounding that and you will have a good idea of what I am concerned with. Still, at the end of the day Dockery is going to be a major tool in a lot developers’ (including this one’s) toolboxes for 2014 and probably beyond.

Windows 8: In the consumer market, Windows 8′s RT offering is in a lot of trouble — that is undeniable at this point. Windows Phone suffers much the same fate as Windows RT, though Windows Phone does enjoy a good holding in South America and some other parts of the world. Microsoft has already hinted strongly that they plan to merge WinRT and Windows Phone into one mobile operating system alla iOS. This is a great Idea but is several years too late. It also undermines the “one Windows” pitch that Microsoft has been making for Windows 8 over the last few years. In 2014, Microsoft will still be dealing with the fallout of their bumbling launch and marketing of Windows 8.

Azure: Azure has grown far beyond Windows in the cloud and at the close of 2013 is a rival to Amazon Web Services and pretty much every other cloud offering. I’ve used Azure several times myself over the year and am pretty impressed on the whole; there were some bumps in the beginning and middle of the year, but these have largely been addressed and it looks like Microsoft has some ambitious plans for Azure in 2014. Over the last month or so something called Midori has been leaking out of Microsoft and, though the pundits seem to think it is something to do with Windows on the client-side, my bet is that this is some sort of evolution of Microsoft’s cloud offerings. Either way, 2014 is going to be a good year for Microsoft in the cloud and for Azure.

Mac OS X: Twelve months ago it looked like OS X was veering dangerously toward an iOSification that would have proven intolerable for professional users. With Mavericks however Apple has found a good balance between their desire for control and the reality that the pro-market has been driven to OS X due to its being a UNIX system that has a late vendor for support and an attractive user interface. Despite the apparent back peddling, it is important to note that Apple has gotten one major change in the OS and managed to implement it in a way that is both useful to the average consumer and acceptable to the pro users — this feature is called Gatekeeper. In Mavericks, Gatekeeper does not allowed unsigned applications (to sign an application one needs to be an approved Apple developer) to be installed on the system by default. The key is that this is a default that any sophisticated user can change. However, I must admit that I have kept this default. Going forward, Apple’s belief in signed applications (or perhaps some slightly watered-down version of it) makes a lot for sense for the future of computing and I actively support refusing to install unsigned applications from untrusted sources. If the current path holds, Apple will be balancing making OS X simpler for average users and new users who came over due to the halo effect of iOS while balancing the needs of the professional user market.

Ubuntu / Linux: Canonical has done an amazing job of sullying the Ubuntu name over the 2013 and has done little more than make a fool of themselves with their naïve attempt at breaking into the mobile space. Ubuntu will still be a very popular desktop Linux operating system among new Linux users and will continue to be a major player on the server-side. Canonical the company however will fail to monetize their offerings in any significant way. The only ray of hope would be some sort of re-focusing of the company to be an enterprise focused organization much like Red Hat. Even in that case, Canonical will not be able to be a true challenger to Red Hat in 2014 and it is unlikely that they will even decide to try. The continued flailing of Canonical will contribute to a “brain drain” of passionate and talented Linux enthusiasts out of the Ubuntu community and into other Linux communities. Another side of effect this is that desktop Linux will continue to be the proverbial tempest in a teapot that it has always been. This internal discord will guarantee that 2014 will not be the year of the Linux desktop in any significant way.

That’s it! Those are my foolish predictions for 2014 — foolish as they may be, I am pretty confident that most of them will be, if not correct, then on the right track. I know they are not earth shattering and basically boil down to 2014 will more or less maintain the status quo. In a way, that’s a good thing. If we are constantly reinventing new technologies and never refining the technologies we are already have, then we will always be using unstable and half baked first generation technology. Have a happy new year and feel free to comment on Twitter.

MDNetworking: My Little Networking Lib

Disclaimer: This is in no way a 1.0 codebase and I strongly recommend against you using this in production.

Summary: MDNetworking is a small Apache 2.0 licensed Cocoa / Cocoa Touch library. It is intended to be suitable for use on iOS7+ and Mac OS X 10.8+ but it may in fact be possible to get it working on older version of iOS and OS X. My intention in creating this library is not to make yet another heavy Cocoa networking framework that is going to solve the meaning of life and the world’s problems. I merely want to present a relatively simple and easy to use facade of NSURLConnection and the like.

Contributing: I’m open and welcome contributions from the community, however, any contributions that don’t adhere to the present code-style will be rejected.

Programming Pitfalls: iOS Simulator and Audio Codecs

PitfallThere are some bugs that you fix and brag about to your friends afterward, then there are the ones that are just plain embarrassing. Unfortunately, I’m writing about one of the latter today rather than the former.  You see this pitfall, though no more or less annoying than the others I cover in this series, is made all the more worse by the fact that I should have known better. If you’ve ever listened to an episode of Coder Radio in which I mention the iOS Simulator, then you know that I always warn developers to never trust it; the reason for this is that your code isn’t really running on iOS but rather a pseudo-OS X platform. Never ever trust the simulator. Ever.

Taking a step back, let’s look at the issue. I have a number of audio files and they all play just fine on the iOS Simulator, but my beta testers are reporting that they can’t hear any audio files at all on their devices. This is odd to say the least. I scoured my AVAudio implementation looking for the most obscure of bugs but still found nothing. The good news, using “good” very loosely, is that I was able to delete the app and reproduce the bug myself.

After a few hours of pouring over LLDB and various Test Flight logs, I found that everything looked fine: the audio URLs (the audio is coming from a server) all looked fine, there didn’t appear to be any NSZombie related issues, and the audio files themselves seemed fine.  I was totally lost.

Then I remembered something based on an offhand comment I found on a StackOverflow post — the simulator uses OS X’s audio subsystems which differ from iOS’s. In particular, OS X has access to a few more audio codecs than iOS. As it turns out, the API I  was interacting with has different calls that request the audio in different formats. I changed the call to request the MP3 formatted files and was good to go. Facepalm.

I hope you’ve enjoyed taking a look at another programming pitfall and please do leave any comments on Google+ or Twitter. Also, please keep in mind that I am always available for consulting projects.

Play Means War

google-play-logo11Google IO fever is in full swing and, though there are a lot of interesting things coming out of this year’s IO, but there is only one real threat to Apple’s leading position in mobile Monetization. This is Play Games. Play Games functions a lot like Game Center with a bit more and (naturally) a focus on Google+. Play Games allows many of the features that Game Center does but has one killer feature: it is cross platform, supporting Android and iOS. You might wonder why this matters, but the truth is (according to the Apple App Store top grossing and top paid charts) the developers that are making the most money are the game developers. It has been argued that one of the big advantages that iOS has is that it is the prefered platform for mobile game developers — meaning that they release on iOS only or iOS first.

Play Games looks really impressive, but the most attractive aspect of it is that it is a backed Game Center like service that is not run by Apple. Let’s be honest, Apple makes great devices and some pretty good client-side software, but their backend services leave a lot to be desired. Game Center in particular was crippled when Letterpress — one of the first games to actually take advantage some of Game Center’s more advanced functionality — was released and became an overnight success. The reality is that Apple left this door open by not focussing on backend-technologies and now Google is going to be able walk through it.

If Android is able to generate roughly the same revenue as iOS for developers, Apple will have to act quickly to preempt an exodus of developers. This might sound a little overboard, but there is a frustration in the iOS community in all but the most hardcore Apple fans that Apple’s policies are increasingly hostile toward independant developers, but as long as the business case is strongly in Apple’s favor, Apple can do whatever it wants. If Google was able to change the business story, they’d be changing the entire landscape.

 

No, The Market is not Fine

There has been a lot of discussion recently in the iOS community regarding the so called “health” of the paid application market. My feelings on whether it is better to pay for the software you use to ensure that you are the developer’s main customer are well documented both on this site and Coder Radio, but, for new readers, I am an advocate of paying (and charging) for software. The most recent developer to throw his hat into this debate has been Marco Arment – the famous developer of Instapaper and The Magazine. Marco is a great developer and someone whose work I respect. His post is well thought out and reasonable – up until the last line where he states: “The bar is higher, but the market is fine”. Before diving into how someone as euredite as Arment could be so mistaken, let’s first define what it means when we say the bar is higher – apps now require a “better user experience” and a good deal of marketing to even be noticed by a reasonable number of users.

Yes, I know Apple has changed the world! Users now demand simple and elegant experiences. Isn’t that great? Well, no if you’re a developer, that’s terrible. That’s terrible, because, as a developer, you likely do not possess the design skills or experience to properly design an app of design caliber that a professional designer would. Like developers, designers do not work for free and a gifted designer who has been working in the field for any length of time command and handsome hourly rate. That means that to hit the required level of design, developers need to invest a good deal of capital in it.

Let’s say that you’ve got your design down and you’ve come to terms with your newly shrunken bank account – my condolences on that by the way. What now? Do you just passively wait for users to download your app? Perhaps you pray for users? Do a rain dance? Sadly, there is no evidence to suggest that any of the preceding will actually help your app become successful. Like any product (and yes your app is a product, not some work of self-expression), your app needs to be marketed. There are a lot of ways of to market it an app, though few of them are effective, but none of them is free unless you are a known quantity (like Arment) or able to convince one to push your app. That means you will need even more capital to get advertising for your app.

Like Arment, I agree that the bar is higher for apps than it was just a few years ago, but I contend that the bar being higher is a problem for the average independent developer. Many of these developers simply do not have the capital required to hire a decent designer and effectively market an app. So, if Arment seems to agree that the bar is higher, then how could he be so blind to the issues that poses for small independent developers? The answer is surprisingly simple: Arment is something of a celebrity in the Apple developer world. That means he doesn’t need to spend the capitol that others would to market his apps; In fact, his name and connections do that for him. In short, the bar is higher for all of us, but it is only half as high for Arment.

Wither Webkit?

As you are probably aware Google has forked Webkit and will be calling their fork Blink. Google does not intend to re-merge with the main project at any point in the future and is signaling that they will be adding new features to their rendering engine. As a developer who often has to work on the web or mobile web this is very interesting but also a little concerning.

 

Currently, Blink and Webkit are just about identical, so we can still feel secure in our Webkit “monoculture”, but the situation will likely change in a year or less. Even if Google makes an effort, as some have suggested that they might, to not break standards or chooses not to push Blink specific features, web developers are still going to have to deal with yet another rendering engine. Sure we’ve already been dealing with a number of them and have gotten used to having to append our CSS with “–webkit” or “–moz”, but Google is not adding a “–blink”. Instead, developers will have to dig into a settings screen to enable or disable functionality. Bottom line there is that there will be Blink specific functionality that some developers will likely want to user; for example currently NACL only works on Chrome and Dart VM works best on Chrome – in other browsers code written in Dart has to translated into traditional JavaScript. There are also a number of rumors floating around that Blink may focus on optimizing HTML5 graphics performance on ARM devices.

 

The question really becomes not what Google is going to do with Blink but rather what are the rest of the Webkit team going to do without them? Google and Apple have been the driving forces around the project and more and more Google has been taking point on a lot of the more cutting edge issues; for example, Google has been pushing performance more than any other contributor to the project but, for the most part, Apple and others have been able to benefit from Google’s efforts thanks to the free software nature of the project’s license. Given Apple’s less than enthusiastic embrace of developers using web technologies to develop for their platforms, it seems unlikely that they would be inclined to match Google’s pace. In a lot of ways, give that Apple’s business model is to sell expensive hardware, a good browser is just another feature on an Apple device, however, for Google, the browser is the primary platform.

Progress is a good thing for web and I am confident that Google’s decisions will yield web developers some pretty cool tech to work with, but there is also the risk that web developers will start relying on those tools too much and we will end up back in an IE 6 / ActiveX situation. Questions? Comments? Dogmatic rage? Please feel free to contact me on Google+ or Twitter. This post was brought to you by Code Journal for Mac.

Errors of 2012

Code Journal Logo2012 has been an exciting year for me, as I released my first commercial OS X App under Fingertip Tech, INC this year. Overall, the experience has been great and I am really enjoying all the great user feedback and am happy to report that a lot of users truly enjoy using the app. However, there have of course been a few missteps along the way.

Marketing: This is the biggest one by far. It is truly amazing what a positive effect a tweet about your product can have on your sales. Unfortunately, I didn’t realise this and failed to allocate enough capital for a proper marketing campaign. I am not talking about purchasing reviews here of course, but it is a reality of the current app marketplace that it is very hard to get a lot of traction without a significant marketing push.

Service Dependency: This is a closed second to my marketing misstep. Like Tweetro and so many developers before us, I have found that developing and maintaining an app that is built upon a third parties service is more than a little challenging to say the least. I won’t beat a dead horse here, since you’ve probably heard this from a number of other developers, but do not do this. Just a small example of one the most minor issues you will face: yesterday Github.com went down and stayed down for an extended period of time and I recieved a deluge of e-mails from frustrated users who could not interact with the service via the app because of this. The unfortunate truth is that if all or even a significant number of those users had decided to one-star the app instead of seeking support from me, sales would have been significantly impacted.

Like so many before me, I am unlikely to develop an app based off of someone else’s service again.

Distribution: Code Journal is currently sold on both the Mac App Store and its own site. Sales have been about equal in both places — some weeks favoring the site and other weeks the App Store. Overall, sales have been good, but since the sales are split about equally, the App Store ranking is significantly lower than it would be if all of the sales had come from there.

On the other hand, it has taken at least twenty (20) days for each update to be reviewed and approved in the Mac App Store. That’s simply too slow, since I have been trying to iterate quickly.  Also, the App Store does not give me direct contact with my users and that’s something I greatly value

Focus: In many ways, Code Journal has been a success and I very happy with how it is performing. However, I’ve lost a significant amount of time and wasted a significant amount of energy attempting ports of the app to a number platforms using a number of tools. Code Radio listeners will know that there was a Mono port and a QT prototype already. What they don’t know is that there have been others — even a Java version. All of them were not satisfactory and were in many ways the lowest common denominator for whatever platform they targeted. I still hold some hope for QT in 2013 to bring truly powerful cross platform development, but, at least for now, the best apps will always be the ones written with the native toolchain.

So, what do you say, did you release a product / project this year? Questions? Comments? Find me on Twitter and Google+. This post was brought to you by Code Journal and Fingertip Tech, INC.

Pricing: We’re Doing It Wrong

Like many of you I am an independant software developer and have found some success leveraging the App Store. Many developers, myself included, have bought into the low price / high volume business model and we’ve had some mixed results…. I’ve been considering the pricing issue for a while and have come to an odd, but by no means original, conclusion: we are all underpricing ourselves. Please note before you read this that I am excluding games from the equation here

This might sound strange given the rise of freemium software and the general wisdom that cheaper software sells in higher volumes. However, it doesn’t seem to hold up.  Taking a fast look at the current top ten grossing paid applications on the Mac App Store, the average price of an app is $75 and the most commonly appearing figure is $20. Now before you get too excited about that $75 figure keep in mind that the average is shot up by a few apps at $200 or more. Also, keep in mind that I am using the ‘top grossing’ for my metrics rather than ‘top paid’; I’m using ‘top grossing’ because it isn’t clear what it means to be a ‘top paid’ app but an app’s gross revenue is an accepted metric I can use to judge its commercial success.  A few other things I’ve noticed from looking at the top grossers: none of them is $0.99, none of them is $1.99, none of them is even $4.99, and the lowest priced apps are $20.

To be honest, I don’t know what price points we should all be hitting, but anything below $4.99 for desktop software seems like far too low; in truth, I am starting to feel like the $4.99 price point is even a bit too low given how much work we put in our products. All I know is that we (software developers) need to end this race to the bottom on price.

Comments? Questions? Drop me a line on App.net, Google+, or Twitter. Also, pickup Code Journal.