A former community discussing the business of software, from the smallest shareware operation to Microsoft. A part of Joel on Software.
We're closed, folks!
Doug Nebeker ("Doug")
I asked this question here a year ago. But a year is like 100 years in our business. So a year later, I think it constitutes a brand new question.
We sell over the internet. Our web traffic looks roughly like this in 2014
02% All others
Every year Windows is less and less. In our niche, we must address all of the 4 big platforms to remain competitive. Our solution was QT. This worked out great for Win/Mac.
For iOS and Droid we stayed on QT and have been developing on their alpha and beta versions. This strategy has obvious business risks associated with it. But I did it anyway.
I really want to hear what others are doing about this issue.
What is your strategy for multi - platform development?
Are you trying to keep it all in one development environment and language?
Are you running multiple projects in separate IDE's and languages at once like Objective C for one, Java for another, and C++ for another?
Web Traffic isn't at all the same as product usage. I browse on my iPhone, but don't own a Mac or iPad, so only a Windows app would be of interest to me. Can you account for that in your stats?
But to your point, I'm not as far as you, but looking hard at QT because we need to solve the same problem.
My stats tell me: Mac users are 2x as likely to buy as windows. This is not surprising.
This is my second smartphone app. My stats from the first app was that users were literally 5x as likely to download and install on a phone or iPad as they are on windows. People were more open to experimenting with new software on these devices then on the desktops. The first app was just a free one to get my feet wet. So I have no conversion stats.
>> Our web traffic looks roughly like this in 2014
It is incorrect to determine global OS usage based on your own website's traffic. If you sell only tomatoes, you will not get traffic for onions.
I only focus on Windows (developed in C++). But for mobile apps, I am developing apps using Xamarin so that it can cater to iOS, Android etc platforms.
Wednesday, February 19, 2014
OK Whatever my stats aren't your stats. Don't listen to C. he is just a forum troll trying to scare you. He is just a prophet of doom predicting the end.
Every time I bring this little issue up to anyone who earns a living from developing desktop software I always get strong resistance, and even violent opposition. Probably because if it is true it means they either adapt or become obsolete.
Look, I am not the one saying this. I am just repeating what Kleiner Perkins (One of the top VC firms). Gartner (A top Research Firm), Wall Street Journal, and every other expert is saying and proving with stats. My stats just happen to be similar to what they are all seeing.
So what are we all doing to deal with this new Paradigm?
Oh, there is no doubt that the bulk of consumption is moving to phones and tablets away from PCs, whatever the OS. And the bulk of technology usage is probably consumption.
So many categories (music players, video players, games?) are quickly moving to the new platforms. Word processors, desktop publishing and spreadsheets, not nearly as much. It all depends on the niche.
In my case, my app is made of a GUI front end that talks to a back end. The back end MUST be installed on a computer at the customer's site -- it makes no sense to be on a tablet. But the GUI makes a lot of sense to be on all of the different platforms.
Xamarin looks good until you realize you have to have separate projects for each platform (iOS, Android, Windows, etc) which also means you have to know all of the different SDKs. I just don't have that kind of time :(
I hope QT really capitalizes on their position and solves this problem (if possible) -- there are MANY of us that need a solid solution.
Even though I am one of those C++ snobs, Xamarin was starting to seduce me. They are good marketers. Their website made it look so simple. I didn't even notice that there are a bunch of different SDK's. Until Doug pointed that out.
@Gautam Can you share with us what your experiences have been like with Xamarin?
My experience doing mobile/tab development with QT so far:
I am almost finished with my iOS/Droid versions built with QT. We were developing around their bug fixes in the alpha versions. I figured it is going to take time for us to build it anyway so by the time they fixed their issues we should be ready to launch. It looks like we finished first, but they fixed most of the major issues.
It was the first time I worked on an Alpha SDK. For android at one point early in the cycle there was QT bug that would call up the numeric keypad instead of the QWERTY keyboard in certain cases. So we just had to develop some other part until they fixed their bugs. They fixed them though.
The app looks great. But to get them to respond to touch the right way was not possible with pure C++ / QT. I am not sure why. We tried debugging that for a few weeks and then we just gave up. Maybe at some point it will work, but we just couldn't get it to work anywhere near as responsive as native.
Our solution, We put a QML wrapper on it. With the QML wrapper everything is fine for Droid, I can't even tell that it is not native. The program runs in iOS but still some minor issues so we will hold back iOS launch for now. Hopefully the next update of QT will close the loop with iOS as well.
Anybody else have any stories? Solutions? Strategies?
I hope QT was the right choice. But really want to know how others are dealing with this.
I have my own cross platform framework allowing Mac and Windows. However, I still have to design two interfaces to target each. They use different color schemes for one, menus are in different locations, many small differences.
I gave up extending that framework to Linux because there is no such thing as Linux. There are instead hundreds of things called Linux. Sure, a batch file script will compile without too many changes, but GUI stuff is a mess, forget it, market is too small.
With handhelds they are totally different devices. The idea of porting a multiwindow high performance desktop app to run on a phone using a single framework doesn't make sense. Things have to be rewritten from scratch. The user interface paradigm is totally different for one thing. Sure, people do it. And there's a lot of crap software as a result.
Write from scratch if targeting mobile. And don't port at all, you have to create totally new products based on the limitations and strengths of mobile devices.
Wanting to write once run on all is like saying you want to know how to make your toaster wash clothes.
You don't have to support all platforms.
It's a choice and probably not a good one.
Today there are order of magnitude more Windows users that there were 10 years ago and plenty of people were making good money selling software for Windows 10 years ago.
Each platform you mentioned has more customers today than it ever had in the past.
If you can't make money on just one of them, maybe work harder on product/market fit instead of trying to spread yourself thin porting unsuccessful product to multiple platforms.
As Scott said, mobile and desktop are completely different worlds - there are very few kind of apps that make sense on both desktop computer and a phone. In practice, the big successes on mobile are mobile-only, not ports of desktop software.
But if you really, really have to support multiple platforms:
1) Go web-based with mobile-optimized UI
2) Use Java, like JetBrains
3) Use C# (Xamarin/Microsoft), like many Xamarin's customers
4) Write your own portability library in C++, like Sublime Text guy
5) Use existing portability library in C++, like Qt or Gtk or wxWindows (not that I recommend that option personally)
6) Make enough money to hire enough developers to write native app for each platform, like EverNote
Wednesday, February 19, 2014
Regarding Xamarin, their documentation is getting better every day. I'm developing Android applications using Visual Studio and their wrappers are so close to the real SDK that sometimes I read Android dev docs directly.
The main advantage for me is the number of third party components and being able to install and test new components using Nuget. A very disappointing part is the size of the generated application, in my case, 6 MB for a very simple app, no graphical resources, nothing... just 6 activities with standard controls. If you wan't to generate native code, you need to buy the most expensive packet +$1800. Not started the iOS port, yet.
Besides that, I think it is a great environment.
I have been using Xamarin. Haven't had any problems. We have got a lot of help from active forums. And the documentation is good.
>> Xamarin looks good until you realize you have to have separate
>> projects for each platform (iOS, Android, Windows, etc) which
>> also means you have to know all of the different SDKs. I just
>> don't >> have that kind of time
This is not 100% true. The core (non-UI) part can be common for both Android & iOS. You only need to design separate UI for each. Most of it is C# wrapper around the SDKs. So you don't have to learn different SDKs.
Although you have to create separate projects, you can include the same set of files so that the compiler will build for different platforms.
>> A very disappointing part is the size of the generated
>> application, in my case, 6 MB for a very simple app, no
>> graphical resources, nothing... just 6 activities with
>> standard controls.
Yes, I observed this too. May be there is some way out. I think it starts from 6 MB onwards and then it grows slowly.
>> If you wan't to generate native code, you need to buy the most expensive packet +$1800. Not started the iOS port, yet.
No. You can generate native code even if you pay $299 (Indie package).
Thursday, February 20, 2014
Thanks for your feedback on my website.
>> >> If you wan't to generate native code, you need to
>> buy the most expensive packet +$1800. Not started
>> the iOS port, yet.
In fact even under free edition you can publish to app store. Not sure if you mean something else when you say "generate native code".
Thursday, February 20, 2014
I had to redesign the entire UI for mobile. I doubt there is a way around this for most programs.
The reason I needed QML was that the program was not responding to touch in the way native programs did. Sometimes there were delays of half a second to 1 second in the program reacting to touch. Also the animations of menus expanding and collapsing seemed a bit Jerky. QML solved these issues.
Has anyone Tried Marmalade?
"It's a choice and probably not a good one."
This is very true in some niches.
half true in other niches.
entirely false in other niches.
You can see an example of how not adapting to mobile hurt TDAmeritrade from their user comments on Google Play.
Their latest version has OK comments but if you go back a few months to the summer in the comments you can see that a lot of their customers outright left the company, because they couldn't get mobile right.
They are not unique in being forced to adapt. Many companies are forced to address all platforms. I am worried about spreading myself too thin as you pointed out.
Also, it seems to me like the hottest opportunities exist in the mobile/tablet space.
> mobile/tablet space
This is something we probably should clarify when talking about 'mobile'. There will certainly be trouble trying to port a desktop UI to a phone. But IMHO, a desktop app on a decent sized tablet doesn't seem like a bad thing. There are still touch-related issues (ie no mouse hover), but that seems minor enough I'm still hoping to build one UI that works on desktop/tablet. Phone will (hopefully) be a subset of the same project with very small/limited views.
It seems to me that in the end the only things that matters to a single-owner software business are profitability and the time/hassle cost of additional development.
Yes, many people are now using apps on mobile, but what is the profitability of developing on mobile as opposed to desktop, or web? Obviously--as with almost any platform or any domain in business for that matter--there are a few outrageous successes on mobile, but what are the *statistics* on profitability on mobile? Is it *worth* developing a mobile version of an app in terms of expected payoff? Given that the, e.g., iOS world has entrained millions of users to expect apps to be free, or $0.99, and then Apple takes 30% of that, plus $100 to be an official developer (though that's not much...is that a one time fee?)...should one expect to make good profits for the time invested learning Objective C or the iPhone SDK or Xamarin, PhoneGap, etc., etc., etc.? Does increased patent trolling concerns on that platform play into one's considerations? Etc.
My point is, just because platform share is being re-proportioned to better favor mobile doesn't mean profitability share is automatically moving as hard in that direction.
Certainly, aside from say the patent troll issue on iOS, if one can just snap one's fingers and the iOS or Android app springs into existence you should probably do that (unless it somehow devalues the perception of your desktop app?). But it strikes me as a non-trivial amount of work.
@Gautam, regarding native code, you cannot access the Bundle assembly into native code options using less a expensive Xamarin license.
I clarified this here: http://forums.xamarin.com/discussion/comment/44992#Comment_44992
Can you tell why you need this option "bundle assemblies into native code"?
Monday, February 24, 2014
It is not needed, but it is the option that translates your IL code into native code. When we use the other linking options, our Xamarin applications are as native as a .net or Java application. With the native code generation, the assembly is embedded in native code dlls or directly translated into native code, but I don't have any further details. Some people compare this option to using NGEN on standard .net applications and that it makes more difficult to disassemble code.
Even without this option, the deployed application will run on Android or iOS, but as IL.
So this option is not necessary... but a nice to have, as it theoretically would make our apps faster and more difficult to disassemble (reverse engineering).
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz