iOS Arguments for Native App Development

[robwithhair]

I'm an iOS developer but over the years I've had to write many Hybrid applications in Cordova. I frequently find I could make the apps so much quicker using interface builder and swift / objective-c but get forced into writing Hybrid Javascript web apps because that is what managers are 'used to' and because of the promise of 'build once, run anywhere'. I've found you just end up with a really slow clunky app with a bunch of software hacks to work around the specifics each platform requires.

I'm trying to make an argument for native app development to the business owners, who are non technical.

Does anyone have any advice or really great articles they've seen about how to get this point across?

 

[chown33]

Is "build once, run anywhere" (BORA) currently paying off?

I realize this depends to some extent on what the apps do, what the return-on-investment model is (i.e. what's the business case for doing the app in the first place), and the relative costs vs. returns of other development models.

If the app isn't actually being put on other platforms, then there's no benefit to "run anywhere", because there's nowhere else it's being deployed.

If this is being done because the app MIGHT be put on other platforms, then the business managers ought to evaluate the cost of simply porting an already working iOS app.

In other words, say "BORA" costs X. Then say iOS-only costs Y. Assume Y < X. Now, what's X - Y, i.e. what's the cost difference? How does that compare to the projected cost of P, which is porting Y to run on another platform at some future time. If Y + P < X, then iOS + porting costs less than BORA.

If Y < X and P is never done, then management never has to pay for P.

If Y < X and P is deferred, then future cash flow might make Y + P a better deal than X, even though Y + P is numerically more than X.

There might be future rewards to be had by using BORA now, but if the future is far away or never happens, mgmt is still paying the cost for BORA despite gaining no immediate benefits. The Extreme Programming principle here is YAGNI.
https://en.wikipedia.org/wiki/You_aren't_gonna_need_it

The business operating principle is sunk costs are sunk, and if you don't have a sunk cost in the first place then that's a future unrecovered cost avoided.

 

[1458279]

As apps become more advanced and the machines reach limits on speed, the responsiveness of the app becomes more and more important.
Consumers not only want more but they want it to respond quickly. Apple has enjoyed the upper hand for a fast, responsive OS, while VM based systems work, they have an extra layer to work thru.

In addition, native is OEM. Native doesn't have to wait for a 3rd party to come up with a solution.

FB made a huge mistake going with HTML5, they said so.

The ability to get a product out the door is based on the programmer. It's not just an issue of remembering API calls, it's more of writing good reusable code and seeing good solutions to problems. Some only look at the time to write one program without looking at the long term.

Give the same project to 10 programmers and you'll see 10 different completion dates even if the tools are all the same.

 

[PhoneyDeveloper]

What do the big boys do? Facebook, Amazon, Google etc.

They first went hybrid. Then they went native. Hybrid sucks.

 

[AxoNeuron]

I've found that what ends up causing the most delays and makes development slow to a halt is when the project is managed poorly. Bad planning, lack of details, etc. these things can really cause development to slow to a crawl.

Getting that right in a project will save far more time and money than using something like Phonegap or Cordova.

I have personally never liked Phonegapc etc. because while they are cross platform, they often lack some basic frameworks and features that are really critical. iOS and android native apps, on the other hand, have plenty of excellent frameworks.

I recently built a Node.js backend that serves both iOS and Android. Then I wrote both the iOS and Android apps natively in Swift and Java. It was an excellent experience and development moved rapidly. I came up with a really flexible and robust caching system based off Core Data on iOS and SQLite on Android, and it worked really well.

The biggest problem though is updates. In order to take advantage of the latest features, not only do you have to wait for Apple, but you also have to wait for Phonegap/Cordova to implement them well.

Honestly, a well thought-out app design with a good backend should make building the app itself a pretty quick process, making sure the management goes well will save a lot more time than Phonegap/Cordova would.

 

[1458279]

I've found that what ends up causing the most delays and makes development slow to a halt is when the project is managed poorly. Bad planning, lack of details, etc. these things can really cause development to slow to a crawl.

Getting that right in a project will save far more time and money than using something like Phonegap or Cordova.

I have personally never liked Phonegapc etc. because while they are cross platform, they often lack some basic frameworks and features that are really critical. iOS and android native apps, on the other hand, have plenty of excellent frameworks.

I recently built a Node.js backend that serves both iOS and Android. Then I wrote both the iOS and Android apps natively in Swift and Java. It was an excellent experience and development moved rapidly. I came up with a really flexible and robust caching system based off Core Data on iOS and SQLite on Android, and it worked really well.

The biggest problem though is updates. In order to take advantage of the latest features, not only do you have to wait for Apple, but you also have to wait for Phonegap/Cordova to implement them well.

Honestly, a well thought-out app design with a good backend should make building the app itself a pretty quick process, making sure the management goes well will save a lot more time than Phonegap/Cordova would.

+1 on management of the project. I've done it for many years and people never seem to stop with the "oh, yea, we need ______ too"

I don't think cross platform is the biggest issue but I guess it depends on how advanced the app is.

I'm actually glad to hear so many of the tech companies are changing their business model to have less focus on chain of command and more on a flat command model.

 

[dantastic]

Problem is management have seen a power point slide which says that a college dropout can create an app in a week which will run everywhere. They can't un-see this in their heads.
I have found in the past that even the most sound arguments have failed to work against power point slides.

The number 1 problem with development these days is the non technical people making technical decisions above your head. In the world of Agile and Scrum too many non technical people have ended up in roles which require technical input.

If this continues you're better off cutting your losses and move on. (Your situation depending obviously)

 

[tyche]

If this continues you're better off cutting your losses and move on. (Your situation depending obviously)

Or stay and do your job. But yeah, if it bugs you, start looking elsewhere for something that better fits your desires. In my fiery youth I remember all the battles I would get into with upper management trying to show them the right choices they should make. It was all a lot of wasted effort win or lose. If your job is to write a Cordova-based app, do it the best you can regardless if you can make it 50% faster/efficient in obj-c.

When and if someone ever asks you why app performance isn't good enough you can offer an opinion but trying to convince people above you they are wrong is an exercise in futility.

 

[1458279]

Problem is management have seen a power point slide which says that a college dropout can create an app in a week which will run everywhere. They can't un-see this in their heads.
I have found in the past that even the most sound arguments have failed to work against power point slides.

The number 1 problem with development these days is the non technical people making technical decisions above your head. In the world of Agile and Scrum too many non technical people have ended up in roles which require technical input.

If this continues you're better off cutting your losses and move on. (Your situation depending obviously)

This is one of the reasons that some management sucks. In America we see management as a promotion instead of a profession. Many grow up thinking management is where you no longer have to work, you just tell others to work. The truth is the management is a science, it happens to be the one I studied.

 

[dantastic]

Or stay and do your job. But yeah, if it bugs you, start looking elsewhere for something that better fits your desires. In my fiery youth I remember all the battles I would get into with upper management trying to show them the right choices they should make. It was all a lot of wasted effort win or lose. If your job is to write a Cordova-based app, do it the best you can regardless if you can make it 50% faster/efficient in obj-c.

When and if someone ever asks you why app performance isn't good enough you can offer an opinion but trying to convince people above you they are wrong is an exercise in futility.

Yup, I agree. I've no interest in the arguments anymore. I offer my opinion but that's it.
The problem is when you are being held responsible for the poor decisions of someone else. That's then it's time to leave. But like I said, it depends on your situation. If you're cool with it then what's the problem. If you're asked to work long hours for free then I'd look elsewhere.

The best managers I ever had all had a military background.

 

[1458279]

Yup, I agree. I've no interest in the arguments anymore. I offer my opinion but that's it.
The problem is when you are being held responsible for the poor decisions of someone else. That's then it's time to leave. But like I said, it depends on your situation. If you're cool with it then what's the problem. If you're asked to work long hours for free then I'd look elsewhere.

The best managers I ever had all had a military background.

Part of that is probably because in the military they have to get results in a competitive environment.

 

[AxoNeuron]

Problem is management have seen a power point slide which says that a college dropout can create an app in a week which will run everywhere. They can't un-see this in their heads.
I have found in the past that even the most sound arguments have failed to work against power point slides.

The number 1 problem with development these days is the non technical people making technical decisions above your head. In the world of Agile and Scrum too many non technical people have ended up in roles which require technical input.

If this continues you're better off cutting your losses and move on. (Your situation depending obviously)

I agree with this. Fortunately at this point I have the freedom to pick and choose my app development clients, I cannot stand the situation you've mentioned. I've worked with several excellent non-technical managers and some really bad ones, it doesn't take long to recognize the difference.

By the time you are dealing with performance and bug issues it's usually too late to just point fingers at management, I avoid those situations like the plague. I'd rather quit than try to implement an app that will be slow or buggy.

 

[AndyK]

Native all the way, hybrid only gets you so far then the quality just falls off a cliff.

 

[firewood]

AFAIK, none of the top apps (popularity, reviews, or revenue) is a hybrid phonegap-like app. Do your managers want to make a mediocre app or a good one? Let them decide, and then let them be responsible for the low-feature low-quality results.

And do you want to work for managers aiming at mere mediocrity?

 

[chrono1081]

I'm an iOS developer but over the years I've had to write many Hybrid applications in Cordova. I frequently find I could make the apps so much quicker using interface builder and swift / objective-c but get forced into writing Hybrid Javascript web apps because that is what managers are 'used to' and because of the promise of 'build once, run anywhere'. I've found you just end up with a really slow clunky app with a bunch of software hacks to work around the specifics each platform requires.

I'm trying to make an argument for native app development to the business owners, who are non technical.

Does anyone have any advice or really great articles they've seen about how to get this point across?

I too see this mentality. We have it where I work. Its funny because I was hired to rewrite failing Cordova/Phonegap apps natively because they just don't work well.

I've shown numerous times that native coding is far superior, yet with each knew project comes a "Why don't we try X technology, its build once and run on everything" and each time the project goes into development hell and each time I have to rewrite it natively.

 

[firewood]

Here's another argument that might be usable on management. Your app will depend on the layers of software underneath it. These layers will have bugs. The more layers, the more likely your app won't work or will work poorly due to a problem in some layer (3rd party toolkit, etc.) under it. I see no evidence that anyone has successfully sued any of these library providers in order to get them fix bugs more promptly, or increase performance.

But... Apple uses their own native iOS frameworks in their own apps. So Apple is far more likely to fix bugs and include iOS enhancement in that native environment. Add any other 3rd party layers, and you have to go to someone else, and hope they don't just finger point at each other and leave you with a garbage app.

 

[1458279]

Those that have been around a number of projects might have noticed something about human behavior.

Some people aren't real deep thinkers, they don't see all sides of an argument. They can be talked in or out of just about anything.

I worked at a company that jumped from one system to another. The new system wasn't tested and was oversold. It included some custom modules to a mainstream accounting program.

Our IT department never had a failed project from me, my boss or one other guy. We got our jobs done 100% of the time. The new project from an outside company failed and the company lost large clients. It was picked up days before closing and they lost most everything.

people that haven't had failure, tend to think everything will always work. Upper people tend to have little clue as to just how hard it is to make things work.

I had a boss that was told off by his boss in front of me and others. My boss wrote an inventory module that would scan in 1 item every 30 seconds in a fast production setup.

He assigned me to fix it. I dumped all his code and wrote my own. His mistake was opening and closing data tables inside the loop and a few other rookie moves. I finished in about 20 min and he commented "it must have been easy".

This is the important part, others that don't know, think things are easy.

I worked as a programmer for hire. I've heard many, many times "can't you just make it __________" or "I'd do it myself if I had the code..."

People don't alway know what they are talking about, they like simple answers. Those that make things work, understand what goes into it, but we don't alway make the decisions about what tools to use.

I've been burned many times in the past with "quick fix" solutions to complex problems.

Not only do I not like these one code, different language solutions, I don't even like bytecode runtime VM things. It chokes performance over the long run.

 

[chrono1081]

Here's another argument that might be usable on management. Your app will depend on the layers of software underneath it. These layers will have bugs. The more layers, the more likely your app won't work or will work poorly due to a problem in some layer (3rd party toolkit, etc.) under it.

This happened to us with...iOS 8 I think? And Phonegap. There was an underlying bug in the Cordova library and it threw an emergency application into a non-working state and there wasn't a fix for a long time (although to be fair, they did post hack-y workarounds) but thankfully it was enough to convince management to remake the app natively.

 

[1458279]

I don't know if this has been mentioned or not, but there is an age old business reason for sticking with native:

It's also a reason to have well documented code and source control.

Most software projects assume, upfront, that staffing will change frequently; So a good business decision is to use a low-enough common denominator, such as VB, Java, C or C++.

Ori Berger
Thursday, December 11, 2003

http://discuss.fogcreek.com/joelonsoftware3/default.asp?cmd=show&ixPost=94232&ixReplies=38

 

[throAU]

I'm an iOS developer but over the years I've had to write many Hybrid applications in Cordova. I frequently find I could make the apps so much quicker using interface builder and swift / objective-c but get forced into writing Hybrid Javascript web apps because that is what managers are 'used to' and because of the promise of 'build once, run anywhere'. I've found you just end up with a really slow clunky app with a bunch of software hacks to work around the specifics each platform requires.

I'm trying to make an argument for native app development to the business owners, who are non technical.

Does anyone have any advice or really great articles they've seen about how to get this point across?

Depends what you're doing in your App?

If your app runs at an acceptable speed with an acceptable UI without using native code then there is zero reason to go native, especially if your company (like most) has limited developer resources. You will have 2 or more entirely different code-bases to test, debug and maintain with the associated bug trackers, code repositories, etc..

Are you currently shipping on multiple platforms and/or is this a primary concern? Given iOS is <50% of the handsets out there, building cross platform apps makes a lot of sense, if it can be done to an acceptable standard.

 

[AdonisSMU]

Problem is management have seen a power point slide which says that a college dropout can create an app in a week which will run everywhere. They can't un-see this in their heads.
I have found in the past that even the most sound arguments have failed to work against power point slides.

The number 1 problem with development these days is the non technical people making technical decisions above your head. In the world of Agile and Scrum too many non technical people have ended up in roles which require technical input.

If this continues you're better off cutting your losses and move on. (Your situation depending obviously)

So true.... But it's not just non-technical people doing it. Sometimes you have formerly technical people or people technically proficient with other unrelated tech trying to tell the hired experts what they should be doing within the hired experts own field of expertise....

I regularly see Java developers trying to tell JavaScript Devs and FrontEnd Devs what can and can't be done on the FrontEnd.... Then when the UI is a hot steaming pile they say "it's going to be the year of easy" otherwise known as the year where we focus on the user experience for our app....as if it's something you can just focus on for a year....with no accounting for the technical debt or anything else that would go into creating an amazing UI.

I get tickets where the product manager hasn't even thought out all of the implications of what he is asking for. No designs no flow diagrams. No nothing. They just think they can say it and it will happen as they want it if what they say they want is even really what they want.

Then in the scrum planning meeting an army of backend Java Devs think they are going to tell the FrontEnd Devs how they should be doing the job then they wonder why UI team was halved within a single month. Backend development is simply another area of expertise with some but minimal overlap with front-end development....yet "full-stackers" go in with the attitude that they know it all.

There is no such thing as a "full-stacker" for 99% of the people. Everyone in theory can be a full stack developer but that doesn't mean they'd be "good" at it...and in my experience most are mediocre full stackers at best but many are really great subject matter experts depending upon their core focus/interest.

 

[1458279]

So true.... But it's not just non-technical people doing it. Sometimes you have formerly technical people or people technically proficient with other unrelated tech trying to tell the hired experts what they should be doing within the hired experts own field of expertise....

I regularly see Java developers trying to tell JavaScript Devs and FrontEnd Devs what can and can't be done on the FrontEnd.... Then when the UI is a hot steaming pile they say "it's going to be the year of easy" otherwise known as the year where we focus on the user experience for our app....as if it's something you can just focus on for a year....with no accounting for the technical debt or anything else that would go into creating an amazing UI.

I get tickets where the product manager hasn't even thought out all of the implications of what he is asking for. No designs no flow diagrams. No nothing. They just think they can say it and it will happen as they want it if what they say they want is even really what they want.

Then in the scrum planning meeting an army of backend Java Devs think they are going to tell the FrontEnd Devs how they should be doing the job then they wonder why UI team was halved within a single month. Backend development is simply another area of expertise with some but minimal overlap with front-end development....yet "full-stackers" go in with the attitude that they know it all.

There is no such thing as a "full-stacker" for 99% of the people. Everyone in theory can be a full stack developer but that doesn't mean they'd be "good" at it...and in my experience most are mediocre full stackers at best but many are really great subject matter experts depending upon their core focus/interest.

I keep seeing those "full stack" ads and it's a joke. I saw one that wanted min 4 years of Swift. How can you have 4 years with a 2 year old language?

They HR / head hunting people usually don't have a clue what they're doing. They just do a keyword check.

Thinking someone can be really know all those things at the depth they expect show lack of knowledge on the part of HR.

One of the sad things that most newer people don't understand is that if they start with ObjC right now, they'll never catch up to the number of years the jobs will require. It's like you have to wait for a new language to come by, like Swift, and then jump on board as soon as you can. The problem is trying to figure out what's going to take off and what's going to flop.

 

[AdonisSMU]

I keep seeing those "full stack" ads and it's a joke. I saw one that wanted min 4 years of Swift. How can you have 4 years with a 2 year old language?

They HR / head hunting people usually don't have a clue what they're doing. They just do a keyword check.

Thinking someone can be really know all those things at the depth they expect show lack of knowledge on the part of HR.

One of the sad things that most newer people don't understand is that if they start with ObjC right now, they'll never catch up to the number of years the jobs will require. It's like you have to wait for a new language to come by, like Swift, and then jump on board as soon as you can. The problem is trying to figure out what's going to take off and what's going to flop.

The company I work for thinks this way. It's not just HR. They think Java programmers can do anything. They are telling HR to find "full stack" developers. I'm like eek!!! Anyone can do anything but that doesn't mean they should do anything.

Yeah, I have no intentions on writing ObjC other than to replace it with Swift.

 

[1458279]

The company I work for thinks this way. It's not just HR. They think Java programmers can do anything. They are telling HR to find "full stack" developers. I'm like eek!!! Anyone can do anything but that doesn't mean they should do anything.

Yeah, I have no intentions on writing ObjC other than to replace it with Swift.

I've been following the programming job market, many are saying ObjC/Swift or ObjC with Swift as a like to have. So I think it's grabbing a hold in the job market.

 

[AdonisSMU]

I've been following the programming job market, many are saying ObjC/Swift or ObjC with Swift as a like to have. So I think it's grabbing a hold in the job market.

I feel like if you know one you can pick up on the other. I find it rather easy to look at ObjC code and I can figure out pretty quickly what is going on. I wonder if that is just experience or if that is the fact that I read the SWIFT book from BNR.