A small rant about Apple

If you have an app or a book published for both Google Play store and the Apple iTunes store, you must know that one as well:
The second you login into the Google Developer console, you see a neat little dashboard, presenting your apps statistics.
With the iTunes connect portal, you need to press two annoying links before you need to wait a couple of seconds and then, hopefully, you get your daily download graph and stats for your app.

This is annoying.

It's amazing how Apple, which stand for design for most people, offer such poor usability for its developers. And don't get me started about XCode.

Is 7" the new 10"?

7" devices are a rage.
After the success of the first 'wave' of 7" devices (1st Gen. Kindle Fire, Nexus 7), and the iPad Mini cannibalizing both iPad AND iPod sales for Apple, the 7" (to 8") tablet category seems to be taking over the tablet market.

After playing with 7" devices for a while (Both nexus and iPad mini), I can definitely understand why. The form factor is simply more successful than 10" tablets. Easy to hold with one hand (iPad Mini feels as light as a kindle), good enough to work with (Thumb type is possible) - Seems like this is the spot for tablets.

So, while 10" tablets are getting more and more laptop-like (Windows 8 convertibles, for example), 7" devices will get retina-quality screens, and probably become the new form factor size for tablets.

Mobile web and sandboxing

I've had a few discussions in this blog about mobile web vs. native in app development.
One of the major problems with creating a mobile web app was performance. When an app needs to display a large list of items, rendering a huge DOM tree with lots of layers causes app performance degradation, resulting in poor user experience.
Well - The guys at sencha came up with a neat idea - 'Sandboxing', which means fragmenting your content items into small iframes.
The basic motivation behind this is that it's easier for the browser to render lots of smaller DOM frames than rendering one huge DOM tree. With multi core processors (And supporting OSs like iOS5/ Android 4 and above), this approach becomes even more effective.

You can read more about it here.

[Thanks Danny Livshits for the link]

Android app published... Some impressions.

After sorting out all the issues, along with some GUI tweaks, I finally got around to publish the application at the play store. (Get it here!)

Publishing process was a breeze - Compile the code in release mode, create a signing key, sign the app, upload (Along with promotional graphics), click publish, and that's it!

Seems like Google has the policy of 'garbage in/ garbage out', which means that rather than testing your app thoroughly (Like Apple do), which makes the whole publishing process take ~8-10 days, your app gets published instantly.

Which means that if an app sucks, Google counts on the crowd to rate the app accordingly. If it crashes a lot, or dead on arrival, you receive reports via the developer console, and can also 'unpublish' the app, update it as much as you want to etc.

Though I prefer the Apple way, which means that even if the app sucks, it still passes the bare minimum for usability, but I'm quite sure that this process helped android catch up the gap in 'total number of apps in the market' with iOS...

Young Letters - Tales of the Android project.

I've started working on the Android version for my young letters application.
Because I'm working with phonegap, I was quite sure that Android porting would work seamlessly, and boy was I wrong...

Getting started was easy. Download Eclipse, Android plugin and SDKs, define the project and setup the phonegap plugin was quick and painless.

However, my code didn't work.
First off, the newest version of phonegap (2.0.0) has some bugs. Seems like after the major overhaul from 1.x, several things (Like playing sound...) were left undone. So I've decided to revert to the same phonegap version I'm using in iOS (1.8.1), which solved the problem.

Some code issues, like resource file paths (Base path on android is different) and HTML5 canvas behaving differently than iOS webview were solved.

Orientation handling is also different than iOS: With Android, it's harder to define orientation changes behaviours (Young Letters is only landscape, for now). In iOS it's a breeze, just select the supported orientations, and you're good to go.

And then I was left with one major issue, which I'm handling now: The variety of android devices and viewports. With iOS, there's only one variation of a screen. The width/ height ratios stay the same between iPhone versions (iPhone 5 supports that ratio as well by framing the extra inch), but with android devices, you have to implement an adaptive HTML view.

Though it was solved in the native environment, the major lesson I've learned was to use percentages and dynamic placements of buttons, rather than set layout (Like I'm doing on iOS).

Then I need to test it with several devices, and see that it works.

Finally there's the whole publishing process in the Google Play store, but we'll get to that once the app is ready!

Updates, new app, new gadget

A month and a half after I've decided to go for it, young letters hebrew is available.
The whole process was quite easy and smooth, though I've had one rejection due to iPad 2x mode compatibility.
Currently app has no analytics connected to it (Next month probably, along with feedback and some UI changes), and now let's see how it catches on.

http://itunes.apple.com/us/app/young-letters-hebrew/id552401430?ls=1&mt=8

English app version will follow up.

You might also see some new recommendations content gadget on my blog: My friends at engageya are providing these, which are very useful in driving more traffic to your (As well as other) blogs.

My other friends in dSero have a great solution for surpassing ad blockers, which is also crucial for the blogging community - Seems like there's a lot of new cool initiatives regarding the blogging community, which, in some ways, has replaced editorial journalism.

As for this blog, other than testing purposes, no commercials are expected in the near future.

In vacation... Notes about devices.

Having the need to be connected even during vacation, I took an iPad (3rd gen) alongside my new galaxy nexus phone.
After using those two devices for a while, here are some insights:

• Android has caught up with iOS. Jelly bean, google voice, google now and other touches (app swapping, the software buttons, a great, huge screen) make my wife's iPhone 4s seem old. 
• Even the form factor of the nexus (and the new s3 as well), the curved shapes, the soft buttons - make apple's device look old. Apple better come up with a killer iPhone 5, otherwise they're in trouble.
• Considering the fact that the next nexus device is also around the corner (rumored November), things seem interesting in the mobile market. 
• I've finally understood the difference between the iPad 2 and the new iPad. I knew that the new screen is great, but only after moving from 2 to new, and working on the new for a while, you get to understand the meaning of a large retina screen. Everything looks analog. You can't see pixels. Amazing. 
• I've played with the new galaxy note tablet, and though it's amazing fast, it's still no iPad. But android devices are catching up. Can't wait for a retina-like jellybean powered tablet. 
• If the next MacBook air has retina, I'm in.
• Still no word from iTunes store about my app - submitted 8 days ago. Waiting sucks. 

Mountain Lion, bits and updates

I am writing this post via Mountainlands dictation feature apparently this feature works quite well

(Mountainlands = Mountain Lion)

"I'm trying to use punctuation, feature in the month of life"

(Month of life = Mountain Lion)

Apparently, the only thing dictation doesn't understand in my accent is the name of the OS :)

App development is progressing well. Debugging and testing in my iPhone is really simple, as long as you've got the right XCode version/ iOS etc.
Registration of devices and the whole certification process takes a little effort, but also works seamlessly.
The next step would be recording some narrations, and then (Try) and publish the app.
I've opened up a page for the app on facebook - Come say hi.

Testing the water with a new iOS app.

A couple of weeks ago, I was looking for a fun educational app for my kids.
I've found out that all related apps aren't free, and most are crap. Real crap.
Deciding that something which I can easily implement should not cost, I've started to fiddle with it, and built a simple web prototype in a couple of hours.
When it was nearly ready, I loaded the page on my phone, and gave it to my girl to fiddle with.
Looks like she liked it, I tested it with a couple of my friend's children, and decided to make it an app.

As it's a very simple idea, I've decided to keep it simple, with an entry screen for parents to brag in Facebook that their kids are playing with my app, and also decided to use phonegap (Just so that I'd be able to easily create an Android version, if I wanted to).
Phonegap installation and integration with xcode is very simple, and it also has a cute Facebook native extension, using either the native app, or the web interface for approving posts. (Though for iOS6 it won't be necessary, as Apple would have its Facebook integrated inside its SDK)

The next step was enrolling to Apple's iOS dev program.
Due to the fact that I live in Israel, and not registering myself as an american company, I have to fax (!!!) a purchase form to Apple, along with credit card info. I know, this seems ridiculous.

A lame start, but I'm determined to have my first app published!

I will post more soon, after I begin the app approval process with Apple.

Want to get rich by creating a killer app?

Well, you most likely won't.
There aren't many companies making direct money from selling app in either iOS or android devices.

Let's do the math.
Suppose your app costs a buck per user.
Now suppose your app has a million paid downloads.
This means 1000000$ in revenues.
An average app would cost you 100000$ to make. (Most cost more, some less)
Now take out Apple's 30%, your of making the app and taxes, and all that's left is ~300000$.

While no small change, this isn't exactly retirement money.

However, if you could sell your app to 1 million users, you're probably doing something right - and get the attention of some big companies, or easily fund your next app.

Still not convinced? Let's do some simple math then.
Apple has given app developers (Up to now), ~4 billion dollars in revenue share. Divide that by 4 years since the store exists, and assuming that the cost of a developer is 100K$ per year, this means that in average, 10000 people (A year) are making their living from this revenue.

The others are losing their (Or other people's) money.

But now let's think of a different strategy:
Make it free, and earn from... well... um...

Not everyone could make lots of money from apps. Actually, except for high end games or the occasional hit, no one does. Most companies have app driven services and value, which generate revenue - That's a more probable model.

So the next time you've got a brilliant idea for an app and want to consult the techie that would invest 6 months of work for 50% shares, think what you're really offering him, and don't be offended if he politely says 'no'.

;-)

Why go native?

... When you've got HTML5?
That's one question I get asked a lot in the past year.

When you've got so many cool new features in HTML5, and want to save development costs, is there any reason at all why your application should be native?
Why write for several platforms, go through the whole approval process (Difficult with Apple, less so with Android)?
Why maintain more than one environment, expert types, development environments? (And yes, I know about Flash Air Mobile, Aptana and Phonegap. And no, I don't consider them as 'native'.)

Well - There are several reasons why you would want to go native.

First reason to go native would be performance.
If you have long tables to present, large stream of information, graphics (Like dynamic maps), you might be better off native.

Second reason is better usage of your device's resources - Camera, GPS, accelerometer - These are all supported/ to be supported in html, but would not work as well as they would with native interface.

Third reason is UI conventions - When programming for a device, it's best to use its native components for UI. Simply put, your users would find it easier to set preferences and options, and learn the application in the visual language the device uses. HTML5 would never look better than a native app, especially in small mobile device screens.

Final reason would be control. You want your users to be focused in your application, rather than have four browser tabs in parallel. You might not want your users to be able to simply 'browse out' of your application (Without doing a proper cleanup...).

There's also a way to enjoy both worlds:
Applications can talk to their 'web view' programmatically: Actually, the only way to spawn a software keyboard in 'editable' divs (Like web based rich text editors do) was by wrapping your site with a small app, and have the javascript 'invoke' the keyboard via the app.
That means you can wrap a web view with a thin app, and that way get all the focus to your app.

So before you jump to HTML5, which is an obvious answer to which platform you choose, think it over a little bit - Maybe native is the way to go.

In the meantime, I'm really having fun exploring Xcode. It's not that bad, once you're used to the workflow. Of course, this isn't visual studio for windows phone (I consider VS to be the best IDE, with WP no exception), but for now - It's fine.

And, finally, here's an interesting article about a small, smart and very popular company. Instagr.am is one of the coolest companies I know. Click the link below to understand why.
What powers instagr.am

Go Xcode yourself

Got a new Macbook Air 13". It's a neat machine, and osx feels great, even for a windows fan like me.
Office for mac is cool, Webstorm is working, and now I'm brushing my unix skills (Installing mysql and activating the built in php and apache), and setting up my work environment.
The good ol' x40 will remain in the family, and go to my older brother.

Another thing I got a mac for was to begin learning iOS development.
Xcode is the official iOS IDE, and after a little bit of fiddling, I still haven't decided whether I really hate Objective-c, or really misunderstand the language.

The principal is supposed to be simple - Drag and drop stuff to the view, write the outlets (Bad name), write some code and then connect them (By doing lots of ctrl+clicking).

But the Objective-c language is, well, quite weird. And the whole concept is a little more complicated than windows phone IDE, FLEX, or even Android.

I will update more about what I've learned once I do some real programming (Some web request and more elaborate controls stuff) rather than just connecting a slider and button to a label...

In the meantime, I'm really, really enjoying the Air's form factor and great performance. Only minor disadvantage - 13" screen with 1440x900 display = Really really small fonts in some web sites.

FLEX vs HTML5... The showdown.

I've been asked this question more than a few times lately, so I've decided to write some notes comparing between the two platforms.
I am currently leaving out other competing environments like gwt (not good enough), silverlight (why would you?) and javafx (not nearly there).
But first off - Before comparing between the platforms, you should be focused on your needs and target devices:
Does your application require heavy graphics processing? Animations?
Is it supposed to run over smartphones and tablet devices? Netbooks? Power desktops?
Are you able to deploy your application to app stores? Do you have the budget to target several platforms?
What are your performance goals?
Perform that analysis, and you will be able to compare between the two, and find the platform that suites your needs.

So, without further delay, let's begin:

Ease of development:
Advantage flex. Though html is very easy to learn, deploy and even debug, flex can be faster, especially with form based apps. flex has a nice WYSIWYG editor, with fast link to simple code. flex also has great built in graphs and charts, to which data could be easily linked. html is gaining ground, though, with new and better development environments in the pipeline.

Performance:
Advantage html. html is 'native' to browsers, while flex runs inside a browser, over a virtual machine. flex has several garbage collection problems (To which you need to go deeper into actionscript studying), is very cpu and memory greedy, and even takes more time to initialize and load.
If you need to run over tablets and netbooks, html should be the way.
If you do go with flex, consider this: Internet Explorer 8 and up has the best flash performance (According to several benchmarks I've performed). Chrome and firefox are slower, and android web browser is even slower then that.


Deployment:
Advantage html. This one is easy. flash needs a plugin. flash doesn't work over iOS. Flash builder 4.5 is supposed to have an iOS 'workaround' - running flex apps over iOS air runtime environment. IE10 is supposed to be closer to webkit browsers that to IE9, which will bring less browser compatibility issues.

Richness and graphics:
Advantage flex. Though html5 and css3 bring canvas, svg, effects and some other great stuff, flex and flash are still better. html is gaining ground here, though - there are lots of neat canvas javascript libraries out there.


Interop:
Advantage html. Need to open an office document via your app? A java applet? Can't do that on flex.

Documentation and development environments:
For flash builder, you will need a license. Knowledge base is quite large, but not nearly as large as html. To develop html, all you need is a notepad and a web browser.

To summarize:
In my opinion, html is the way to go. Faster, better performance in most cases, cheaper development and setup. Runs over every device, and besides - Everybody wants to develop better and faster browsers, rather than faster flash players...
So on the overall, for now, html wins by points.
But as the time goes by, html is getting better and better. So unless you're doing something that requires the flash platform or requires flash graphics, go with html.