There’s been some solid debate recently around Mac App Store pricing, and the idea of paid upgrades, continual ownership and updates.  It’s relevant, and it is a change in revenue model for software companies.  Will Shipley, always a thoughtful and thought-proking individual weighed in with this opinion.   Largely proposing a way for the Mac App Store (and by inference, I would say it includes the iTunes iOS app store) to provide for paid upgrades on major revisions of the software.   It’s valid from a more traditional point of view on revenue and pricing of software.

A very solid counterpoint was provided by The Mental Faculty in the blog post Paid Upgrades and the Mac App Store.

I believe there is a missing piece there that major upgrades are treated differently, by Apple and others.

My expectation is as follows.   Initial prices for software will drop.   Not to $0.99 or any of that.   Major software is going to cost money.   $10-$30 for a lot of normal apps that might now go for $50-$70.  Those apps will have feee updates for their lifecycle.   Then when a major upgrade is going to be released, it’s a *new* application.   Migrating data will be a bit of a pain in sandboxing and application security, but a bit of Dropbox or other transfer ingenuity will alleviate that.

My rationale?    It comes down to essentially a “license” that you sell for the duration of a version, rather than the duration of a year or the like.   The great part for the customer is the license never expires (unless the software no longer works on an OS upgrade or device upgrade).   The upside for the developer is that you get lower cost for adoption, and you do have a recurring revenue stream for solid bits of new work.   It is a change in the upgrade and sales model.   The other option is to introduce major uplifts in features as paid in-app purchases, which is another option with what already exists.

I don’t think it’s either full price new versions or free upgrades for life.   There’s a lot of capability in the revenue models Apple has in the app stores they run, and while those models are nowhere near exhaustive, they are, I believe, sufficient to support a wide range of development models and companies.

I expect that the iLife and iWork applications will go this way as well, and as that happens, iCloud is how those apps will move across data and settings between versions.   Mountain Lion will be a new app on the app store, even though it’s an “upgrade”.   The supporting evidence is that Apple showed us long ago the OS was a lower cost upgrade than say Microsoft provides.   This gives incentive for people to upgrade much more readily than a higher price point would, yet everyone pays the same price.

Every sale is an upgrade.   From the previous major version to the current version, or the first version to the latest version.  One price upgrades.  Even if it’s upgrading from nothing to a new customer.

John Gruber linked in a study from Purdue about the majority of battery life going into supporting and displaying ads.   Rather surprising really, but largely due to the fact I hadn’t considered it much on mobile devices.   I usually get paid versions of apps as I’m just not a fan of ads eating screen real estate.   That said, I use ClickToFlash to limit ads on web pages and further cull their activity with Little Snitch blocking a lot of track sites and flash serving ad sets.   I’d rather have a way to subscribe, or read inline advertising as Gruber does with Daring Fireball already.   It’s much more effective as well than the pop-over ads and interstitials I go looking for the close button on before the thing even gets rendered.

I wonder if this sort of study is going to affect purchasing decisions in people if it becomes more widespread?   And if that happens it will affect developer decisions and will actually wind up changing some of the ad industry approach in that they too will have to consider efficiency and battery life.   It won’t just be the application developer dealing with the restriction.   The ad is a supporting mechanism, so really it should use no more than say 10% of the resources the application uses itself.   Definitely not 3x the resources at any rate.

In-App Ads Consume Mucho Battery Life:

Jacob Aron, NewScientist:

Up to 75 per cent of the energy used by free versions of Android apps is spent serving up ads or tracking and uploading user data: running just one app could drain your battery in around 90 minutes.

Abhinav Pathak, a computer scientist at Purdue University, Indiana, and colleagues made the discovery after developing software to analyse apps’ energy usage. When they looked at popular apps such as Angry Birds, Free Chess and NYTimes they found that only 10 to 30 per cent of the energy was spent powering the app’s core function.

[…]

(Via Daring Fireball.)

Apologies for the deluge of reposts as I moved everything over.   The original post dates are in the titles of each should you be interested, and things are backed up and configured as needed at last.

So after a few years of being largely idle, Digital Katana Technologies Ltd. is underway and operating.   Currently we are doing work both with software development and coding as well as architecture and technology consulting.   The the midst of that, some time is finally being allocated to work more consistently on the iOS apps Digital Katana has been designing and exploring over the past year.

The blog posts on technology will start to flow and anytime a software release or other company news comes about, the news will be published here first.

So, let’s assume you want to attack using mDNS also known as Zeroconf on Linux to advertise your new service in a modern, portable, discoverable way with no pain on the user’s part?   Simple, just pop over to http://avahi.org and look at the examples.   Compile them, try them out.   If you’re on a Mac, avail yourself of Bonjour Browser to have a look at the services popping in and out of existence as you test it.   There may be a Linux zeroconf service browser, but I didn’t find one ready to go.   If you know of one, please add it into the comments!

Wait, you’re saying you can’t get it to compile and link?   Ah.   Yes, so there’s two normal landmines people step on in Linux development.   The first one can be solved by a general rule of thumb.   You need the avahi-devel packages to be installed so you can use the headers in the examples and in your software that allow you to link into the avahi ABI.  On an RPM-based system, yum install avahi-devel will get you there.   Normally, pacakagename-devel is going to get you these developer libraries.   Avahi is already on most RPM distros so you can have your software run out of the box without this install on the target machine.   You just need it for development and compilation of the binary.

Wait, still not working you say?   Ah.  You’re getting a few pages of “undefined reference” you say?   All to avahi functions?   So you try the link flag -lavahi as that usually gets it right?   No go.   libavahi doesn’t exist.  So you go googling.   I did all this.   It’s an interpretive pain.  Here’s the magic incantation to build the service publishing example:

gcc avahitest.c -lavahi-glib -lavahi-core -lavahi-common -lavahi-client

That links in all the avahi libraries I could find (and you don’t really need them all, but they are listed here for completeness).   Then it runs and works brilliantly.  If you’re wondering where all these are located, it’s in /usr/lib64 at least on x86_64 Fedora.

I wandered through the avahi wiki at some speed, and couldn’t find anything simply listing this time-consuming necessity.  So I’m posting it here in the hopes that a future frustrated searching developer might find just a bit of relief and save themselves a bunch of blind stumbling to little effect.

Currently playing in iTunes: Know Us by Jillian Ann

James Governor over at Red Monk (a great bunch of analysts I alternately seem to agree with and take issue with) posted a take on the mobile platform development continuum and HTML5 as an alternative. Take a read and the disagreement I voice below will have a better context.   I’m reposting the reply here because it is a relevant discussion and I leave him the right to do with his site as he will, and that includes having it go away.   So I’ll keep my work where I can get at it.   On my laptop in MarsEdit and on the web on my own blog as well.  

[I feel] James, [is] getting a bit absolutist for an analyst that usually sees how things fit together more completely.   It’s not a winner-take-all end game.   Some apps work better on a local platform, native toolchain, optimized into the hardware, fixed system, no browser barrier.   Usually have a higher development cost than the average web app.   These are, of course, generalizations.

Just look at the Samsung Galaxy response.   Some people like it.   Different form factor.   Different purpose.   iPad app onto a Galaxy?   Most wouldn’t feel right or be a great experience.   The web gives you a “common denominator” approach, and that usually gets offset by a pile of javascript conditionals adjusting for the nuances of browsers.

I tell you, trying to use a mutual fund screening system on the web today was horribly painful.   The state and ability to pull things in and out of a spreadsheet app is just not happening.   The app is older and could be improved with some newer approached and technology, but really, I want my <em>data</em> to be able to flow back and forth securely between devices, but when I’m working, I want it to be <em>here</em>.   That’s why the browsers keep adding in desktop features.   Because the experience in the browser is and has been inferior.

WebGL?  Offline Storage?  Hardware graphics acceleration?   Codec hardware acceleration?   These are all desktop features that get pulled into the browser over time as it trails behind.   It’s not surprising, and it’s not going to change.  Standards move slower than most proprietary innovation.  Web apps are usually for a cheaper and/or broader approach, with a radically different revenue model.

It just baffles me that development gets lumped into a bucket of “proprietary platform” or “web standards”.  Both are two ends of a continuum.   OpenGL is pretty cross-platform in the bulk of the API.   And it’s well defined on experience.   There’s shades of gray all over.   Are you telling me the same technology and approach for Farmville is appropriate for Doom3 or Call of Duty Black Ops?   I don’t hear the game companies complaining about supporting 5 or 6 platforms, let alone 2 or 3.

Of course, the desktop pulled in automatic updates and notfications and sync from the web in many ways to bring those strengths across too, so it’s not totally a one-way street.

But it’s not a one-lane street either.

Apple may be laying out a foundation of pretty serious evolution in personal communications right under our noses with Facetime.

Facetime is an open spec.  Always good for adoption.  It’s supported by one of the hottest consumer cell phones out there.   It’s data-based, but also rooted in SIP.  Now, if the rumour sites are right, the latest incarnations won’t only go to phone numbers, but to email addresses associated with devices.

Big deal you say?  Think it through for a moment. If you have multiple devices, they register to a single email address.  You have a universal number now.  Any connection to that email address via Facetime (voice, video, however) and you alert every device it’s associated to (or the most recently live one is a default, or user preference) regardless of location.

Ok, so that’s Instant Messenger on many devices.  Again, big deal you say.

SIP can associate a phone number in there as well of course, and the phone has a phone number in there, but let’s theorize something.

Let’s say for theoretical argument’s sake that Apple replaces AIM as the mobileme transport with this “universal iContact system”.  Anyone on it with an iChat client or Facetime device (iPod, iPhone, iPad, Mac (again, theoretically, we’re forecasting)) can connect to anyone on any of their devices with a voice, video or even plain text or data session at any time.  SMS goes bye-bye as it’s just a typed text chat line to the facetime address.  You have a new unlocked iPhone 4 and you pick up a local data plan wherever you travel to and all your “calls” are forwarded automatically at local rates for data.   Roaming charges to bye-bye.

Now let’s say the Apple creates a SIP gateway that can associate the iContact ID with a phone number they provide, sort of like a SkypeIn number or other “real” phone number in a voice system.   When the call goes to that number, it gets forwarded as a translated Facetime voice chat to any and all of your associated Facetime iContact devices, and you pick it up just like a Grand Central number (Google Voice now).

Apple has replaced present-day mobile phone numbers with a universal number, added in the video calling, text chatting, voice calling and crunched it all down to data streams on a standardized open protocol.  The cell companies finally are reduced to data plan sellers (which is all they *should* be charging us for today anyway, the rest is restricted repackaged data at ridiculous markups (read: SMS)) and the roaming charges that get travellers so irate are gone without losing contact by having local sim cards and phone numbers everywhere.  Now it’s starting to look like a big deal.

Deploy VOIP and messaging as a primary avenue with a bunch of features everyone thought were in the future 20 years ago (video calling) and already have a device that’s creating a critical mass.   Lump all that on top of the ability for other device manufacturers to jump on the bandwagon with compatible services and offerings, and we finally get connected in a quality way, a universal way, and a fair way, and it happens soon.

It may even be happening now.

This is a weird one. Apple finally (and rather late really) announced the WWDC 2010 dates and such. And dropped a bit of a shocker on the long-standing Mac developer community.

The Apple Design Awards, long coveted as awards recognizing some of the best in design, performance and functionality on the Mac, and recently on the iPhone OS (including iPod) this year are only accepting iPhone OS apps and iPad apps. ADAs for apps that haven’t even been shipping a full quarter? And NONE for the Mac. You can’t nominate anything that doesn’t have an app store URL.

This really seems a callous slap in the face of Mac developers. Somebody has to make the Mac good for more than just developing iPhone apps, and these guys do it. But that seems to have been lost on Apple this year.

Looking at the session overview though, I have a theory of sorts on this and what’s coming up.

The sessions are VERY heavy on iPhone OS, mostly iPhone OS 4. There are Mac streams as well, but really mostly specialized streams. There’s also no IT stream listed this year. That’s another big break from last year.

No, I don’t think Apple is bailing on the Mac platform, and no I don’t think they are going to kill off development on it or on the server OS. What I do think is they wound up with a year of heavy focus on iPhone and the iPad, and that actually drained their engineers away a lot from the rest of the work. Let’s face it, they put a pile of effort into Snow Leopard in the guts, with OpenCL, the LLVM stack, GCD, and an acre of other bits. This year it’s iPhone OS 4 that looks like it’s really chewing up a lot of time, plus they need to get the iPad onto that release as well (I’ll bet that’s to be announced at WWDC this year).

So I’m going to predict that 10.7 is not coming on the usual release cycle. I think we’re looking at WWDC 2011 will be a resurgence on the Mac side as it will likely be an off-year for iPhone OS in many ways as they enhance 4.0 and start thinking about 5.0. WWDC 2011 will preview 10.7 that will have some of the iPhone OS showing up in the touch interface capabilities, possibly with some new hardward in the iMac line with touch screens in the fall, and 10.7 released with those. The level of quality that Apple usually churns out I think has actually stretched them on this one, and they can’t keep 3.5 product lines cranking, being the Mac, iPhone, iPad and the 0.5 of the iPod being an adjusted iPhone. So they wind up with sort of an iPhone/iPad/iPod year of WWDC with a minor Mac focus, then (hopefully) a major Mac focus with a minor mobile, or even more ideally for both groups (though expensive for those with feet in both ponds) they split to have a mobile WWDC and a Mac WWDC.

Then the ADAs could have mobile ADAs and Mac ADAs. And all would be a bit more balanced again in the universe. Maybe even the odd Universal ADA for software like OmniFocus that spans all of them. If all the platform implementations are good enough.

Rogue Amoeba (great products BTW) really puts forth the specifics. And gets closer to what is going on in the review process at the app store. Read their pain over here.

All these complaints (they aren’t the only ones that have seen horrid inconsistencies and nonsense) are the sorts of things that happen when scaling breaks, and breaks hard. You hire a bucket of people to get the glut moving on approvals, but many of them really aren’t sure as to the purpose or strategy of it, so they stick to the letter of the law regardless of the sensibility so they don’t lose their jobs, and hammer out procedure blindly.

The idea that it is a public API that they are using to get these images is the crux of it. Even with a knowledgeable employee going to bat, the procedure over-ruled the spirit of the policy, and the denial flew out of Apple’s walls. It should be painfully obvious to anyone with a quarter clue about Apple software development that Rogue Amoeba are doing the exactly right thing, for the right reasons, and giving the best experience with the tools openly provided by Apple.

This should have been approved. If you’re an app dev, retweet this. Blog about it. Make it obvious. Apple has been listening and changing policy and procedure, as well as reversing a number of blatant rejection mistakes when it gets loud enough. This item shows a flaw in the process that is pretty core to the experience, and Apple has actually degraded user experience with this errantly-enforced policy. Anybody that deals with Apple products knows this isn’t the outcome or user experience they want. It’s obvious Rogue Amoeba is doing it right, and the approval process is seriously broken with a very specific case to illustrate it. This can be fixed. All the facts and details are in the article.

C’mon Apple. Fix this nonsense. To the app devs that are feeling these pains, make it this specific. Make it clear the principles at stake and what you did to try to explain it to the reviewers. Then publish it and get people talking about it. We can get them to fix this mess. They want to, at some level, and getting the information put together clearly for them is the first step. Getting a lot of the other devs to crank the volume by engaging the discussion is the next step.

Losing this caliber of developer on the platform hurts the platform Apple. These are the guys that are leads on the Mac, and should be listened to on the iPhone long before the rest of us.

This seems to be getting a lot of play today: Facebook iPhone app developer hands it off and goes on to other projects: At TechCrunch

The thing that seems to be completely missing is what he finds so objectionable. There’s a quick jab that he’s opposed to the very existence of the review process. So it’s political/philosophical? I suppose his work at Facebook and how it reflects on that company isn’t reviewed by anyone and he’s totally free and unfettered to produce the good, the bad and the ugly as he sees fit?

There’s a lot of things wrong with Apple’s review process, but compared to my experience with Palm and Blackberry, there’s a whole lot less crap coming out on the platform in comparison. I can’t prove that’s credit to the app store, but I suspect there’s a chunk of credit due there. There’s a lot of issues with it as well in rejections from Apple on overlapping or confusing interface and conflict with built-in applications. I think the difference is that Apple is trying, and succeeding to varying degrees, to provide a more consistent level of experience with the platform. That’s bringing a lot of pros and cons to what we can and can’t do as developers on the platform, and there is a big obfuscated review system inbetween the devs and the customers. It’s different, and it’s far from perfect, but I think there’s benefits there worth pursuing and working to improve with Apple.

Now, if you could put together competing app stores, that would be quite interesting as well. I wouldn’t mind some competition on that side. On the opposing view, the worm that’s trashing up iPhones in Australia is on jailbroken iPhones running applications put out by devs that are very competent, but they aren’t reviewed and they aren’t within the confines of Apple’s restrictions and systems. I think that’s an indicator that there is some end-user benefit to the way Apple is doing this. And keep in mind, as developers, that’s who we are here for. The Users. Not ourselves and our own political agendas.

I really like the Facebook iPhone app. Would have shelled a few bucks out for it was it a paid-for app. I’m sorry to see a talented programmer bail on the platform over Apple’s policies, but he has every right to do so and make his opinion heard. I just wish it had a bit more meat on it than being opposed to “the very existence of the review process”.

I’m sure that more platforms will put in review processes actually based on the success of Apple, but others will not. The users will decide with their wallets which one contributes to a more desirable product and platform. I’m pretty sure we’ll have both models for a long time to come.

Let’s Kill the OS Upgrade Disc – CBS News: “

Not having an upgrade disc is what the Mac OS X series has had from the start. Even Snow Leopard is that way despite the fact you are supposed to be on Leopard to pay the upgrade reduced price rather than full box set price. Snow Leopard is a bit of an outlier at any rate.

But this guy is saying just put in a subscription. Apparently he didn’t hear the corporations that paid just such a subscription to Microsoft and got nothing for it screaming for blood a few years back. And again was not listening too closely when that fee gave them Vista and broke rather sizeable chunks of their software and IT processes.

No way. If Mac offered a subscription for OS upgrades, even then I would say only maybe because sometimes old software you need breaks and you can’t upgrade until it’s ready to go. And until it’s ready, I’ll keep my money. With Windows, it seems you pay to break the majority of your software for home users, being games and fun bits that aren’t always written so well or on enduring APIs.

Applications, on the other hand, I’m all for his approach. In-app upgrades, fully downloadable. Of course, most of the solid apps do that already. At least on the Mac. Sorry, but I’m still amused at the catch-up. People seem to think the Mac is fan boy base and not capability. I got onto this platform after running Windows, Unix and Linux as my primaries for many years. I went to it because it works, and it’s higher quality. Losing some software options was outweighed by having this sort of capability and maturity already there for the past half decade. And it keeps getting better. I’m not turning the clock back. It’s just good to see another platform, especially the dominant one, trying to at least start to move forward at last.

Now about that WinFS thing……..