Archive for Mac OS X

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.

Code Journal 1.4.0 Update

Code Journal LogoI am Happy to announce that Code Journal 1.4 has just been released on the Mac App Store. We took special care to respond to your feedback both in terms of performance and of course new features.

I am particulary fond of the new less wordy way we are naming and dealing with repositires in the title bar and also we’ve added the match requested manual refresh button. For a more complete list of changes, please see the release notes on the App Store.

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.

Code Journal 1.3.3 Released

I’m happy to share that Code Journal for Mac version 1.3.3 is now available on the Mac App Store. This build includes a few small tweaks including splitting off from the iOS Github tokens and now has a friendly message for users who have no incoming activity in the Github feed.

Hope you like it!

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.

The Best Feature…

Code Journal LogoI’ve been hard at work mapping out the future of Code Journal  and took some time to go through user e-mails that requested new features; the idea was that I would simply implement the feature that the most users had e-mailed asking for. That feature was a resizable UI.

The problem was that the people, my customers who I of course care a great deal about, were very passionate about this particular feature and the feature seemed simple enough to implement; after all, I’ve implemented resizable UI’s on a number of Mac OS X apps for clients, so why couldn’t I apply the same the techniques to Code Journal? Right? Wrong.

Code Journal started out pretty simple; it was an app that pulled and processed JSON data from the Github API; in fact, the most complicated thing in the private demo (think alpha) version of the app was Github’s OAuth. I was thrilled. The app was nice and simple.

Overtime and as it closer to the all important 1.0, compromises had to be made. There is no need to enumerate them here, but suffice it say that one current feature (Github Enterprise support) is responsible for a disproportionate amount of code and almost all of my support requests. Does that mean I’ll be pulling enterprise support? Absolutely not. The truth is that these request have more to do with customers having non-standard settings on their Github Enterprise deployment or the server that host them, rather than anything to do with Code Journal. Enterprise support is a slam dunk and I personally love being able to user Cde Journal with clients who have Github Enterprise servers; best part is that most of the time all I have to do is fill out the enterprise field in the app with my credentials and we are good to go — no need to bother a sys-admin at all.

In short, the complexity that supporting enterprise customers caused was a good thing. Back to the feature request: resizable interfaces.  I understand why some people might want this feature, but, to be honest, I don’t think it’s a good idea. Even on my 27 inch Cinema Display, I often find myself pressed for screen real estate when tacking some hairy memory management problem or am “in the zone.” Like many of you, I am not willing to compromise by putting my monitoring tools into a separate space and, again like most of you I imagine,  I only have the one screen. The other issue of course is that Code Journal is a Mac app and a lot developers that work on Macs work on 13” laptops.

Still, it’s hard to ignore your paying customers, so I went against my instincts and began coding.  I won’t bore you with the details, but it was doomed from the jump. I spent two weeks coding and agonizing over resizing table views and experimenting with Auto Layout. What resulted wasn’t terrible but had a number of rough edges and, more importantly, was not a feature that I could see myself using and believe would have been a major source of maintenance. The feature is not going to be released. At this point in the product’s life, it is more important to keep complexity out of the equation than to add every suggested feature; this particularly true of features that don’t provide any additional functionality. The best feature is the one you never have to maintain.

Comments? Questions? Share them with me on Google+ or Twitter. This post was made possible by Code Journal and Fingertip Tech, INC. If you are Github user please check out Code Journal and if you are interested in having an Android, iOS, or web app developed please contact me. Also, check out the new free version of Code Journal for iOS.

 

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.

Macbook Air for Development

If you have been following me on Google+, you may know that my beloved Macbook Pro had a little accident; I was working late and was extremely tired and I dropped my full mug of coffee directly onto my Macbook. That’s right the entire mug of steaming hot coffee went directly into my almost two thousand dollar laptop. Desperately, I began to dry off the machine and attempted to use compressed air to force out the moisture. I did this for some time  but finally had to go to sleep. All I could do was wait. In the morning it became clear that my machine was a doorstop, so I drove to the nearest Apple Store and made a purchase.

 

The laptop being replaced is a Macbook Pro 13” i7 with 8GB of RAM. By any measure it is a powerhouse for a laptop; full disclosure it has had some trouble with kernel panicking that I believe were due to overheating.

 

As usual the Apple Store was jam packed, so I had to wait to speak to an employee, but that was fine, since I had not yet decided what to buy. I knew I wanted an Air; my experience with my XPS 13 has sold me on the virtues of SSD’s and frankly traditional spinning drives feel a bit antiquated to me know.

 

I also looked at the retina model for a few minutes. I can’t deny that it looks very pretty, but the web is not retina yet and the cost is a bit more than I want to spend; I have been going through a Mac laptop about one every eighteen months, so spending over two thousand dollars on a machine seemed foolish to me. Another point regarding resolution is that the Macbook Airs are all higher resolution than the machine that I was replacing and they look stunning.

 

If you can’t figure it out already, I bought an Air. I had thought that I needed to have the same amount of RAM as my pro, but, having done some research and having worked on my XPS a bit, I came to the understanding that an SSD really makes the most difference for the type of work I do on my Macs: iOS and Mac development.

 

For the stat minded, I got the 13” Air with 4GB of RAM and the 128GB SSD hard drive. Or in other words the base 13” model. How’s it going? So far so good.

 

Comments questions? Find me on Google+ or Twitter.

Effects of App Store Distribution pt1

Those of you who follow me here or on Coder Radio or on any of the social networks that I frequent will know that I have been running a little experiment with my new Mac Application Code Journal; for those of you who randomly got here via a search or something like that, the experiment was trying to sell a consumer target Mac OS X application outside of the Mac App Store. No need to go into too much detail, since if you want more info you can go check out episode ten of Coder Radio, but the experiment did yield a result and a lot of feedback. Basically, there is ample evidence to support the idea that, in general, apps that target OS X will do better on the App Store than via direct sales.

As with the mobile space, I believe that increased reliance on app stores will have some considerable effects on the business of app development, the developers, and the apps themselves. So I am writing this three part series to discuss those issues and am taking something of novel approach (novel to me at least): I am going to look at this issues by comparing two very different apps Mars Edit, and my own Code Journal. I picked Mars Edit as a point of comparison because it is established and is in a different space than Code Journal, so there isn’t any risk of bias. Additionally, in many ways Mars Edit can be seen to represent the traditional Mac application model while Code Journal more closely resembles the single purpose “app ideal”.

The eight hundred pound gorilla in the room is app pricing. In general it is becoming increasingly hard to sell an app for more than a few dollars; some would argue that even getting the few dollars at all is really hard. Of course, there are exceptions to this, but those tend to be from either large game companies (think EA, Activision, etc) or from established Mac developers. An example of the latter would Daniel Jalkut’s Mars Edit, an app that is currently selling for $39.99 on the Mac App Store. Mars Edit’s success is a great story but also very atypical of pricing for productivity apps in the store and a lot of that may be due to Jalkut’s and the app’s cache’ in the Mac developer / enthusiast community; again for those who don’t know Jalkut was a former Apple engineer and has been fairly active in the community. Additionally, Mars Edit was successful long before Jalkut took it over; he actually bought the app from another developer in 2007.  A quick survey of competing apps in the same space on the store showed that most of Mars Edit’s competitors tend to be in the ten to fifteen dollar range and seem to have poorer placement in the store, which suggests weaker sales. One notable exception is the $39.99 MacJournal; Yes, there are of course other applications on the store that charge more, such as OmniGroup’s OmniPlan, but  we are looking at its competitors here.

What does this all mean? Honestly, Apple is the only who has the data to be able to truly say if the store if pushing prices down across the board. There certainly seems to be a correlation in applications being priced lower and the rise of the app store model, but there is an alternative argument (with an alternative villain) that could be made: free web apps may be forcing prices of native apps down by training consumers that a large class of applications should be free, such as Google Docs. Again, Apple is really the only who can disprove or prove the first point for sure and the web app debate is something for another day.

Check back soon for a look at what the App Store seems to be doing to independent software developers.

If you have some feedback please find me on Google+ or Twitter. Also, if you like my posts or work on Coder Radio, please consider purchasing Code Journal either from the Mac App Store or direct.

Lessons Learned: Code Journal Early Release

As you may know Code Journal had its early release last week and it has been a pretty good experience so far. I got lots of great feedback from users and have already been able to update the application based on that feedback.  The purpose of this post is to share some of the lessons I have learned and create a discussion around independant software development and distribution. I could enumerate all the nice things that have been e-mailed or otherwise communicated to me re Code Journal, but I believe that there is more to be learned from criticism than praise, therefore, I am going to discuss some of  the application’s critiques.

Critique #1: Mountain Lion Only!?!?
Yup, I heard this one a lot. I decided to develop the application for Mountain Lion, because I thought a few 10.8 specific features were essential and that most of the application’s users would quickly upgrade to the new OS. Turns out that even though Apple reported record adoption of Mountain Lion (OS X 10.8), a large set of Code Journal’s potential users are running older systems: mostly Lion (OS X 10.7). The good news is that despite my miscalculation, I was able to rectify the situation quickly; I have already updated the app to support 10.7+ and I am happy to say that the updated version has been live for several days now.

Critique #2: No Pasting Passwords?
This one caught me a little off guard but really it shouldn’t have looking back. You see I have this odd habit of memorising long passwords, so typing them out is a pretty routine task. Most sane people, however, are using something like LastPass or a similar tool. I am happy to report that I have an update to Code Journal in testing that does allow the pasting in passwords and, unless any issues are found, that version will be pushed live early this coming week.

Critique #3: No App Store Version?
If you are a Coder Radio listener (and you should be), you will know that I am doing something of an experiment with Code Journal. Basically, I have not released it on the Mac App Store intentionally to see how that would affect sales and what (if any) feedback I would get regarding its distrobution. Before I mention what feedback I got I should say that this was the single most common critique of the app. In short, a lot of people have a strong preference to get all of their apps from the Mac App Store and do not want to purchase apps from a website. This is good news for Apple, but bad news for devs; I still hold that there is significant value in having a direct relationship to the users of your apps and the delays caused by Apple review process (22 days for Code Journal’s first binary) can be incredibly damaging if your strategy is to build and iterate rapidly. Assuming that the feedback I received is representative of the greater Mac user ecosystem, it seems that the Mac App Store will soon be the only feasible portal via which to sell apps; barring games that might do well in Steam.

Critique #4: What is Gumroad and Why Isn’t It PayPal?
This is another one that really surprised me, but it seems that there a lot of users who are not really comfortable entering their credit card data into Gumroad. Taking a high level look at my data I have x sales but x * 30 sales have ended right at the checkout screen. Think about that for a minute. The vast majority of people who like the info page enough to click “buy now” got all the way through the checkout process and turned back at the final checkout screen. The data aside, I have heard from several people that they or others close to them were not comfortable with entering the credit cards into Gumroad and would strongly prefer that I switch to PayPal. So why Gumroad at all? Well, they do a lot for me for the same cost as PayPal including verifying receipts, sending app updates to users, and a number of other small things that I would have to implement myself with PayPal. I am still considering how to handle this issue.

Bottom Line
In many ways I feel direct distribution has been incredibly successful, mainly because it allowed me to react quickly to user feature requests (back porting to Lion etc), however, the Mac App Store issue is a troubling one; if the percentage of Mac users who strongly prefer to purchase apps via the Mac App Store continues to grow, developers will have little choice but to conform to the somewhat draconian sand-boxing policies of the Mac App Store. Having said that, I am not against distributing Code Journal via the Mac App Store. In fact, if the numbers continue as they have (numerous users declining to purchase until an a version is on the store), then I probably am not going to have much of choice.

Comments? Questions? Find me on Twitter or Google+.