or Connect
AppleInsider › Forums › Mobile › iPad › Apple Inc's new Swift language a "huge leap forward for iOS ecosystem," offers "enormous opportunity" with IBM in enterprise
New Posts  All Forums:Forum Nav:

Apple Inc's new Swift language a "huge leap forward for iOS ecosystem," offers "enormous... - Page 2

post #41 of 73
When 'programming' gets to the point where one can create their own assets and then verbally or textually describe to Siri or Watson what you want done with those assets (in other words, the A.I. performs the coding for you), then I'd do nothing but 'program' all day.

Proud AAPL stock owner.

 

GOA

Reply

Proud AAPL stock owner.

 

GOA

Reply
post #42 of 73
Quote:
Originally Posted by Dick Applebaum View Post

It pretty much guarantees that if an app compiles it will not crash at runtime.

That would be a major academic achievement and, if true, would have been the first thing out of their mouths at WWDC.

post #43 of 73
Quote:
Originally Posted by ascii View Post

Quote:
Originally Posted by Dick Applebaum View Post

It pretty much guarantees that if an app compiles it will not crash at runtime.
That would be a major academic achievement and, if true, would have been the first thing out of their mouths at WWDC.

Actually, it was the third  thing out of their mouths when describing Swift:



They didn't dwell on code safety other than showing some unsafe constructs in Obj-C that go away with Swift -- it's kind of hard to demonstrate.
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
post #44 of 73
Quote:
Originally Posted by Macky the Macky View Post


I too didn't expect there to be a connection between the Swift language and the IBM partnership. I hadn't heard the 20% to 60% numbers before. When did Cook say that? If that is their goal, then that will indeed blow the lid off of sales of iDevices. In fact a 60% penetration of Exxon alone would be worth breaking out the century-old champaign.

That hole out behind Microsoft's Redmond offices needs to be expanded to hold all the Surface Pro 3s. When filled and covered, I understand there will a break dance exhibit done on the mound... that is after Ballmer does his obligatory monkey dance.

IBM has an army of 10,000's of developers/contractors around the globe, and a way to productize a custom developed app (they have another army of 10,000 tech writers and marketing folk).   IBM sees enterprise problems, can develop the solution on the clients dime (client funded R&D), generalize it with a low infusion of product development $$, and push it out the door to every other enterprise client.

 

Given IBM's Analytics/Big Data bent,  iOS integration into their analytics engines on big @ss IBM Virtual Data Center homed DB2 data farms  is a big market.   And in the Enterprise, keeping up with the Joneses, is par for the course.

 

As for Exxon Penetration... champagne?  likely not.  Assuming that half their employees use laptops, and half of those can switch, that's only 20K iPad sales.  that's about 4 hours of sales.  But if Exxon makes that move, then others will see less risk in it.   

 

What you really want is something like the US Postal Service developing a custom app that makes an iPhone the primary mobile computing tool for a letter carrier (338,000 in the US alone).  

 

Nurses/healthcare.   2.7Million nurses involved in healthcare.  Assume that many more in allied-health (techs, transport, etc).   IBM comes up with an iOS app for an iPad to talk to an IBM based medical records system... All those laptops on carts just fall out the window (literally, they take up more space in the charging bay).

 

The real benefit is that once IBM does it, the cost to deliver it to other business drops, it can scale down to small business (the real benefit of the cloud... I don't need a VM mainframe anymore, just an iPad, and a $100 month internet connect), and then it also drops for consumers (ditto).

post #45 of 73
Quote:
Originally Posted by SpamSandwich View Post

When 'programming' gets to the point where one can create their own assets and then verbally or textually describe to Siri or Watson what you want done with those assets (in other words, the A.I. performs the coding for you), then I'd do nothing but 'program' all day.

 

No thank you, I have a hard enough time trying to get Siri to dial the correct Pizza service. Piazza Domination Hoes this is Elga, how may I punish you today, yeah, do you guys sell anchovies. I would like to see more IDE's offer better interfaces that incorporate a more visual approach to programming, elements you can simply drag and drop, easily selectable sources like database, RSS, other XML files, delimited files, selectable workable algorithms, etc. Out of the three main mobile OS's, iOS, Android and WM8.1 and the IDE's that are offered for them, I think I prefer programming with MS's tools, if you go here  http://appstudio.windows.com, you can in 4 easy steps create a very usable app. Pretty cool little interface, I made an app in less then an hour that shows all of my subscriptions from AppleInsider, click on one, takes me to the last page, ready to post. It's a silly thing I know, but I have added notification support now that WM8.1 just got a Notification Center. Though I know how to write a Windows mobile app from scratch using Visual Studio, using a simple GUI that starts you with a working model is not only a perfect way to learn but makes it faster to produce simple tools, a lot of fun too. I also absolutely dig the virtual machine, it's so great that you can visualize your creation every step of the way.

When I looked up "Ninjas" in Thesaurus.com, it said "Ninja's can't be found" Well played Ninjas, well played.
Reply
When I looked up "Ninjas" in Thesaurus.com, it said "Ninja's can't be found" Well played Ninjas, well played.
Reply
post #46 of 73
Quote:
Originally Posted by Misa View Post

all web content is PHP. 

 

These guys, these guysthese guys and all the .NET developers might disagree with that.

 

---

 

Objective-C is extremely verbose. While typing may be only a small part of developing software, the more of it I have to do the more chance I have to make a typo. Also readability is essential for maintaining software. Objective-C can be UGLY. Reading extremely verbose code also leads to problems.

 

Swift aligns Apple with modern readability and syntax conventions of languages like Ruby, Groovy, Python and others. Yes, the vast majority of the real work is still done in libraries, but making those calls easier to parse (for the human) is very valuable.

 

While I'm primarily a Java developer, I've started using Groovy wherever I can because it cuts out a lot of verbose boilerplate that Java requires. I can get to the problem rather than writing lots of housekeeping code to keep Java happy.

 

I think Swift will make it easier for coders in other modern languages to jump in and out of Swift than Objective-C does.

post #47 of 73
Quote:
Originally Posted by TheOtherGeoff View Post

Quote:
Originally Posted by Macky the Macky View Post

I too didn't expect there to be a connection between the Swift language and the IBM partnership. I hadn't heard the 20% to 60% numbers before. When did Cook say that? If that is their goal, then that will indeed blow the lid off of sales of iDevices. In fact a 60% penetration of Exxon alone would be worth breaking out the century-old champaign.


That hole out behind Microsoft's Redmond offices needs to be expanded to hold all the Surface Pro 3s. When filled and covered, I understand there will a break dance exhibit done on the mound... that is after Ballmer does his obligatory monkey dance.
IBM has an army of 10,000's of developers/contractors around the globe, and a way to productize a custom developed app (they have another army of 10,000 tech writers and marketing folk).   IBM sees enterprise problems, can develop the solution on the clients dime (client funded R&D), generalize it with a low infusion of product development $$, and push it out the door to every other enterprise client.

Given IBM's Analytics/Big Data bent,  iOS integration into their analytics engines on big @ss IBM Virtual Data Center homed DB2 data farms  is a big market.   And in the Enterprise, keeping up with the Joneses, is par for the course.

As for Exxon Penetration... champagne?  likely not.  Assuming that half their employees use laptops, and half of those can switch, that's only 20K iPad sales.  that's about 4 hours of sales.  But if Exxon makes that move, then others will see less risk in it.   

What you really want is something like the US Postal Service developing a custom app that makes an iPhone the primary mobile computing tool for a letter carrier (338,000 in the US alone).  

Nurses/healthcare.   2.7Million nurses involved in healthcare.  Assume that many more in allied-health (techs, transport, etc).   IBM comes up with an iOS app for an iPad to talk to an IBM based medical records system... All those laptops on carts just fall out the window (literally, they take up more space in the charging bay).

The real benefit is that once IBM does it, the cost to deliver it to other business drops, it can scale down to small business (the real benefit of the cloud... I don't need a VM mainframe anymore, just an iPad, and a $100 month internet connect), and then it also drops for consumers (ditto).


Your comments, and my monthly retirement check from IBM, are making me feel good about Big Blue again 1biggrin.gif
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
post #48 of 73
Error
From Apple ][ - to new Mac Pro I've used them all.
Long on AAPL so biased
"Google doesn't sell you anything, they just sell you!"
Reply
From Apple ][ - to new Mac Pro I've used them all.
Long on AAPL so biased
"Google doesn't sell you anything, they just sell you!"
Reply
post #49 of 73

Swift is indeed a big improvement wrt Objective-C. After a learning curve, it will reduce the development time for app developers.  But the main drawback remains: like its predecessor it is an Apple only language. 

As a developer of smartphone apps I have to listen to the market demands and make my apps available for both iOS and Android platforms.  Porting an app from one platform to  another typically requires 50% additional effort and cost.  So currently I try to stick, whenever possible, to Cordova/Phonegap which makes it possible to develop cross platform smartphone apps.


Edited by cropr - 7/26/14 at 12:58am
post #50 of 73
Quote:
Originally Posted by cropr View Post

Swift is indeed a big improvement wrt Objective-C. After a learning curve, it will reduce the development time for app developers.  But the main drawback remains: like its predecessor it is an Apple ony language. 
As a developer of smartphone apps I have listen to the market demands and make my apps available for both iOS and Android platforms.  Porting an app from one platform to  another typically requires 50% additional effort and cost.  So currently I try to stick, whenever possible, to Cordova/Phonegap which makes it possible to develop cross platform smartphone apps.

What I'd really like to see happen is for Apple to embrace the open source side with Swift. Microsoft doesn't like the open source community much at all and there's some uncertainty over C#:

http://en.wikipedia.org/wiki/C_Sharp_(programming_language)
http://www.fsf.org/news/dont-depend-on-mono

If Swift became the main language for iOS and Android, they could drive C# and maybe even Java out. It would also allow apps like Unity and maybe other SDKs to use the language directly. This allows 3rd party SDK developers to directly call Apple's OS APIs and possibly avoid cross-compiling through XCode. One problem there might come from people not liking Apple directing the language's features but it wouldn't be much different from Oracle controlling Java. Once the language reaches an acceptable level and is open source, there shouldn't be significant changes that disrupt workflows.

Beyond that, they can push for Swift support in browsers and web servers because if Google takes it on, they can support it in Chrome and that can become the language for Chrome OS too. Google tried to get a new language adopted called Go but they never gave an incentive to use it. If they had tied it to Android and Chrome OS development the way Apple will do with iOS and OS X, it would have gained much better adoption.

The platform-specific APIs would still hamper portability but having a common language helps a lot and it shouldn't harm Apple in any way to do this. They'd just be expanding their pool of developers.
post #51 of 73
Quote:
Originally Posted by Paul94544 View Post
 
Quote:
Originally Posted by Macky the Macky View Post


In any good diverse ecosystem there are important niches for bottom-feeders and sucker fish.

Don't forget the Babel fish - Dude

 

And the wrecks split into millions of fragments.

"If the young are not initiated into the village, they will burn it down just to feel its warmth."
- African proverb
Reply
"If the young are not initiated into the village, they will burn it down just to feel its warmth."
- African proverb
Reply
post #52 of 73
Quote:
Originally Posted by Relic View Post

As a Java Enterprise programmer, why would I want to use a programming language that isn't cross platform compatible, isn't that the whole point. No, I see web driven apps replacing Java not Swift, maybe a few will utilize it for specialized apps that require their apps to be ran locally.

using java and thinking you're writing cross-platform apps is a mistake. a java app on multiple platforms just means you have an app that looks poor and behaves unusually on multiple platforms. native is superior.
post #53 of 73
Quote:
Originally Posted by NolaMacGuy View Post

Quote:
Originally Posted by Relic View Post

As a Java Enterprise programmer, why would I want to use a programming language that isn't cross platform compatible, isn't that the whole point. No, I see web driven apps replacing Java not Swift, maybe a few will utilize it for specialized apps that require their apps to be ran locally.

using java and thinking you're writing cross-platform apps is a mistake. a java app on multiple platforms just means you have an app that looks poor and behaves unusually on multiple platforms. native is superior.

Someone said ... "Java: Write once -- debug everywhere!"

And, if web-driven apps are the answer -- what was the question 1confused.gif
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
post #54 of 73
Quote:
Originally Posted by Dick Applebaum View Post

Quote:
Originally Posted by NolaMacGuy View Post

Quote:
Originally Posted by Relic View Post

As a Java Enterprise programmer, why would I want to use a programming language that isn't cross platform compatible, isn't that the whole point. No, I see web driven apps replacing Java not Swift, maybe a few will utilize it for specialized apps that require their apps to be ran locally.

using java and thinking you're writing cross-platform apps is a mistake. a java app on multiple platforms just means you have an app that looks poor and behaves unusually on multiple platforms. native is superior.

Someone said ... "Java: Write once -- debug everywhere!"

And, if web-driven apps are the answer -- what was the question 1confused.gif


Relic raised some good issues. First, cross platform compatibility. Apple hasn't said anything about opening Swift up to other platforms, and it may not happen soon, if at all. Swift is still beta and Apple has warned that Swift will undergo a lot of changes over the next two years. I'm even wondering if it will remain beta during that whole time span. If so, it wouldn't surprise me if Apple doesn't open it up to other platforms until that phase is complete. Secondly, I thought web-driven apps had been declared a closed issue. I must have missed a memo. As far as "few will utilize it for specialized apps that require their apps to be ran locally." My understanding is that IBM is all over Swift as a programming language. We will see what the next two years may bring.
"That (the) world is moving so quickly that iOS is already amongst the older mobile operating systems in active development today." — The Verge
Reply
"That (the) world is moving so quickly that iOS is already amongst the older mobile operating systems in active development today." — The Verge
Reply
post #55 of 73
Quote:
Originally Posted by SpamSandwich View Post

When 'programming' gets to the point where one can create their own assets and then verbally or textually describe to Siri or Watson what you want done with those assets (in other words, the A.I. performs the coding for you), then I'd do nothing but 'program' all day.

I can see it now. Only two years hence as the human race reckons the illusion of time.

I gesture to my iDevice which summons a hologram of Siri from her virtual bath. (that girl spends most of her time in soapy water).

"Siri," I say, "Let Watson know I need an app written. There are three specifications. First, Watson needs to search his Big Data and find a human need that has not been realized yet and write an app to fulfill that need. Second: It must be a need strong enough to trigger the auto-buy on enough iDevices that it brings me $10,000 a month. No, make that per week. Finally have it on the Apple Global app store before tomorrow. I need the cash for this weekend."

"Oh, Siri, have the lout, Ballmer, bring my limo around to the front. I feel an invigorating drive through the country to cool back down after this little mental workout."
"That (the) world is moving so quickly that iOS is already amongst the older mobile operating systems in active development today." — The Verge
Reply
"That (the) world is moving so quickly that iOS is already amongst the older mobile operating systems in active development today." — The Verge
Reply
post #56 of 73
Quote:
Originally Posted by Dick Applebaum View Post


Someone said ... "Java: Write once -- debug everywhere!"

And, if web-driven apps are the answer -- what was the question 1confused.gif

Those Java programmers weren't very good. ;)

 

Web applications are defiantly the present and future, I think I mentioned this before but when I was healthier and working I was employed by the largest bank in Switzerland. I was the managing director of internal programming, though we utilized compiled applications for specialized solutions such as our our trading platform the bulk of our applications were web driven. It's exactly the same situation in almost every company, in every field. Even the applications that ran specifically on a tablet, such as the iPad were for the most part web driven. Yes, I'm sure company's will utilize all those wonderful new apps that IBM will produce but mark my words any internal custom solutions will most likely be web driven and not compiled using Swift. No company in there right mind is going to send any of their programming staff to school to learn Swift just for the sole purposes of making iPad apps, not when they could easily make a web app in less time, less money, utilize the talent they currently have and especially use those apps across their entire IT infrastructure. There will of course be those exceptions, specialized apps are always needed but for the most part they will be purchased from third party vendors.

 

Swift is a clearly a very clever thing but it will not be shaking up the Enterprise world anytime soon as most here believe. I've seen many different programming solutions and languages come and go, those that stuck and were utilize the most were the ones that could be used  multiple hardware and OS environments, i.e. Java, Python and web applications. it's just the way it is, things like running naively, faster, intuitiveness of the UI, whatever, just isn't a match for portability, speed of releases, budget constraints, especially when the output is identical. 

 

Those who will benefit from Swift the most are company's or individuals specifically selling iPad apps.

When I looked up "Ninjas" in Thesaurus.com, it said "Ninja's can't be found" Well played Ninjas, well played.
Reply
When I looked up "Ninjas" in Thesaurus.com, it said "Ninja's can't be found" Well played Ninjas, well played.
Reply
post #57 of 73
Quote:
Originally Posted by NolaMacGuy View Post


using java and thinking you're writing cross-platform apps is a mistake. a java app on multiple platforms just means you have an app that looks poor and behaves unusually on multiple platforms. native is superior.

Then honestly your Java programming team is sub-par if they can't get their applications working the way they're supposed too. I've heard this many times in forums but when it comes right down to it, writing and supporting multiple versions of one app to run on different platforms is no match for writing it once, supporting just that one build and then using it on the multiple platforms. It's fine to think that Apple's solution is superior and more company's should be using it but what are the real benefits, speed, not really important, reliability, sure but your delusional if you think a company wouldn't expect a programmer to make sure their Java version isn't also reliable, look and feel, not important, it's all about the output in the end. For the most part Enterprise apps are data entry, data retrieval, reports and calculations, things that can be accomplished with a web app and there isn't much that can't be done with HTML5, PHP/Python/Ruby and a Oracle/MySQL/PostgreSQL database. 

When I looked up "Ninjas" in Thesaurus.com, it said "Ninja's can't be found" Well played Ninjas, well played.
Reply
When I looked up "Ninjas" in Thesaurus.com, it said "Ninja's can't be found" Well played Ninjas, well played.
Reply
post #58 of 73
Quote:
Originally Posted by Relic View Post

Quote:
Originally Posted by Dick Applebaum View Post

Someone said ... "Java: Write once -- debug everywhere!"


And, if web-driven apps are the answer -- what was the question 1confused.gif
Those Java programmers weren't very good. 1wink.gif

Web applications are defiantly the present and future, I think I mentioned this before but when I was healthier and working I was employed by the largest bank in Switzerland. I was the managing director of internal programming, though we utilized compiled applications for specialized solutions such as our our trading platform the bulk of our applications were web driven. It's exactly the same situation in almost every company, in every field. Even the applications that ran specifically on a tablet, such as the iPad were for the most part web driven. Yes, I'm sure company's will utilize all those wonderful new apps that IBM will produce but mark my words any internal custom solutions will most likely be web driven and not compiled using Swift. No company in there right mind is going to send any of their programming staff to school to learn Swift just for the sole purposes of making iPad apps, not when they could easily make a web app in less time, less money, utilize the talent they currently have and especially use those apps across their entire IT infrastructure. There will of course be those exceptions, specialized apps are always needed but for the most part they will be purchased from third party vendors.

Swift is a clearly a very clever thing but it will not be shaking up the Enterprise world anytime soon as most here believe. I've seen many different programming solutions and languages come and go, those that stuck and were utilize the most were the ones that could be used  multiple hardware and OS environments, i.e. Java, Python and web applications. it's just the way it is, things like running naively, faster, intuitiveness of the UI, whatever, just isn't a match for portability, speed of releases, budget constraints, especially when the output is identical. 

Those who will benefit from Swift the most are company's or individuals specifically selling iPad apps.

I suspect your enterprise experience is a lot more current than mine -- when I left IBM in 1980 there was no web.

I retired in 1989, and didn't touch a computer again until 1997 ... To get myself current, I taught myself JavaScript -- and implemented a web site with a shopping cart entirely in JavaScript.

Later Perl, then ColdFusion which was built atop Java.

I haven't done any for pay development since my wife Lucy died, suddenly, unexpectedly in 2001.

So, I'm a dilettante -- I piddle around and program for my own amazement -- and a few things for friends and family.


Much of what you say is true -- especially cross-platform, platform-independent points.

Here are some things I found out researching Swift.

Swift runs on a thing called an LLVM -- which stands for Low-Level Virtual Machine -- similar to the Java JIT ByteCode compiler, but designed to be closer to the iron. They soon realized that the LLVM could be used for a lot more than runtime execution -- things like writing tools and compilers.

Microsoft, Google, Sony and Apple * have LLVM development environments in various stages of testing and production.

So, it is possible that LLVM will realize the promise of Java for the desktop and web server-side programming.

* Apple's XCode has been transitioning to LLVM for several years and it is mostly complete.

Quote:
Today at WWDC 2014, Apple announced the beta availability of a new programming language, Swift, which is set to ship with iOS 8 and OSX Yosemite later this year. Swift is a high-level programming language that will be familiar to JavaScript developers, but is compiled using LLVM to produce highly performant executable code for both OSX and iOS platforms.

Apple has heavily invested in LLVM technologies, which provide an abstract instruction set that can be translated for specific architectures. Clang replaced GCC as the compiler of choice for C and Objective-C programs, and both of those are translated with Clang into LLVM instructions, which are then optimised into an executable for the platform. The new programming language, Swift, produces LLVM bytecode in the same way and can co-exist with existing Objective-C applications and libraries.

In addition, swift also comes with a REPL environment for testing code. Normally used by interpreted languages such as JavaScript or Python, a REPL provides a Read-Evaluate-Print Loop that can be used to evaluate individual expressions and statements at the command line for easy debugging. Combined with powerful looping, string interpolation and printing/debugging options, it allows an interactive style of development and testing that is frequently missing for compiled languages such as C and Java.

http://www.infoq.com/news/2014/06/apple-swift



Now, the designers of the LLVM have a goal for a mobile LLVM.

Quote:
Apple and Google Together Again?
Considering the size of Google’s operation, this is a wonderfully impressive hack. But like Vikram Adve back at the University of Illinois, the company wants more out of LLVM. It wants to achieve something akin to that “write once, run anywhere” nirvana.

The search giant is also using LLVM to create a tool that can safely run any code inside a browser on practically any machine. Still under development, this tool is known as Portable Native Client, and you can think of it as a kind of uber browser plug-in. In many ways, it echoes the original goal laid down by Lattner and Adve: a programming paradigm somewhere between Java and machine code.

Adve questions whether Portable Native Client will find success — browsers already have JavaScript — but believes that LLVM may achieve a similar success on mobile phones. He envisions a world where you can use LLVM not only to create applications that can move from machine to machine, but that can move from across different types of processors on the same machine — from, say, CPU to graphics processor.

http://www.wired.com/2013/07/apple-google-llvm/all/


It's an interesting read!


One final point: Apparently, Apple started writing Swift in 2010 using LLVM/CLANG -- As the language syntax and definition solidify, I suspect that Apple could make it open source ala WebKit ... Or other platforms can write their own implementations.
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
post #59 of 73
Quote:
Originally Posted by Relic View Post

Quote:
Originally Posted by NolaMacGuy View Post

using java and thinking you're writing cross-platform apps is a mistake. a java app on multiple platforms just means you have an app that looks poor and behaves unusually on multiple platforms. native is superior.
Then honestly your Java programming team is sub-par if they can't get their applications working the way they're supposed too. I've heard this many times in forums but when it comes right down to it, writing and supporting multiple versions of one app to run on different platforms is no match for writing it once, supporting just that one build and then using it on the multiple platforms. It's fine to think that Apple's solution is superior and more company's should be using it but what are the real benefits, speed, not really important, reliability, sure but your delusional if you think a company wouldn't expect a programmer to make sure their Java version isn't also reliable, look and feel, not important, it's all about the output in the end. For the most part Enterprise apps are data entry, data retrieval, reports and calculations, things that can be accomplished with a web app and there isn't much that can't be done with HTML5, PHP/Python/Ruby and a Oracle/MySQL/PostgreSQL database. 


Yes, but the HTML 5 solution uses a lot of bandwidth -- sending down the wire:
  • verbose CSS
  • verbose Javascript
  • verbose XML or JSON (usually as web services)
  • verbose HTML
  • images
  • links
  • cookies
  • multiple connections

Paraphrasing US Senator, rtd Fritx Hollings:

"Day's a whole lotta' bandwidth consuming' goin' on out dare"


Now, off to have some raclettes 1biggrin.gif
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
post #60 of 73
Quote:
Originally Posted by Dick Applebaum View Post


I suspect your enterprise experience is a lot more current than mine -- when I left IBM in 1980 there was no web.

I retired in 1989, and didn't touch a computer again until 1997 ... To get myself current, I taught myself JavaScript -- and implemented a web site with a shopping cart entirely in JavaScript.

Later Perl, then ColdFusion which was built atop Java.

I haven't done any for pay development since my wife Lucy died, suddenly, unexpectedly in 2001.

So, I'm a dilettante -- I piddle around and program for my own amazement -- and a few things for friends and family.


Much of what you say is true -- especially cross-platform, platform-independent points.

Here are some things I found out researching Swift.

Swift runs on a thing called an LLVM -- which stands for Low-Level Virtual Machine -- similar to the Java JIT ByteCode compiler, but designed to be closer to the iron. They soon realized that the LLVM could be used for a lot more than runtime execution -- things like writing tools and compilers.

Microsoft, Google, Sony and Apple * have LLVM development environments in various stages of testing and production.

So, it is possible that LLVM will realize the promise of Java for the desktop and web server-side programming.

* Apple's XCode has been transitioning to LLVM for several years and it is mostly complete.
http://www.infoq.com/news/2014/06/apple-swift



Now, the designers of the LLVM have a goal for a mobile LLVM.
http://www.wired.com/2013/07/apple-google-llvm/all/


It's an interesting read!


One final point: Apparently, Apple started writing Swift in 2010 using LLVM/CLANG -- As the language syntax and definition solidify, I suspect that Apple could make it open source ala WebKit ... Or other platforms can write their own implementations.

Thanks for the info, I love reading your posts,always filled with lovely new stuff to research, I'm still going though it all but so far very impressive. I need to ask though, will Apple provide a Swift runtime for Windows and Linux because without it, well, it's kind of like figuring out cold fusion and only keeping it for yourself. 

When I looked up "Ninjas" in Thesaurus.com, it said "Ninja's can't be found" Well played Ninjas, well played.
Reply
When I looked up "Ninjas" in Thesaurus.com, it said "Ninja's can't be found" Well played Ninjas, well played.
Reply
post #61 of 73
Quote:
Originally Posted by Relic View Post

Quote:
Originally Posted by Dick Applebaum View Post

I suspect your enterprise experience is a lot more current than mine -- when I left IBM in 1980 there was no web.


I retired in 1989, and didn't touch a computer again until 1997 ... To get myself current, I taught myself JavaScript -- and implemented a web site with a shopping cart entirely in JavaScript.


Later Perl, then ColdFusion which was built atop Java.


I haven't done any for pay development since my wife Lucy died, suddenly, unexpectedly in 2001.


So, I'm a dilettante -- I piddle around and program for my own amazement -- and a few things for friends and family.



Much of what you say is true -- especially cross-platform, platform-independent points.


Here are some things I found out researching Swift.


Swift runs on a thing called an LLVM -- which stands for Low-Level Virtual Machine -- similar to the Java JIT ByteCode compiler, but designed to be closer to the iron. They soon realized that the LLVM could be used for a lot more than runtime execution -- things like writing tools and compilers.


Microsoft, Google, Sony and Apple * have LLVM development environments in various stages of testing and production.


So, it is possible that LLVM will realize the promise of Java for the desktop and web server-side programming.


* Apple's XCode has been transitioning to LLVM for several years and it is mostly complete.
http://www.infoq.com/news/2014/06/apple-swift




Now, the designers of the LLVM have a goal for a mobile LLVM.
http://www.wired.com/2013/07/apple-google-llvm/all/



It's an interesting read!



One final point: Apparently, Apple started writing Swift in 2010 using LLVM/CLANG -- As the language syntax and definition solidify, I suspect that Apple could make it open source ala WebKit ... Or other platforms can write their own implementations.
Thanks for the info, I love reading your posts,always filled with lovely new stuff to research, I'm still going though it all but so far very impressive. I need to ask though, will Apple provide a Swift runtime for Windows and Linux because without it, well, it's kind of like figuring out cold fusion and only keeping it for yourself. 

I suspect they will -- and for Android, too!
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
post #62 of 73
eQuote:
Originally Posted by Dick Applebaum View Post


Yes, but the HTML 5 solution uses a lot of bandwidth -- sending down the wire:
  • verbose CSS
  • verbose Javascript
  • verbose XML or JSON (usually as web services)
  • verbose HTML
  • images
  • links
  • cookies
  • multiple connections

Paraphrasing US Senator, rtd Fritx Hollings:

"Day's a whole lotta' bandwidth consuming' goin' on out dare"


Now, off to have some raclettes 1biggrin.gif

 

Actually your network traffic would be almost exactly the same if you were using an native application to access a database or web interface. I think your assuming that just because an app is nativity installed on a device it doesn't have the need to access it's networked data as often. Unless programmed specifically to cache it's data, which is rare as data changes constantly there will still be the same amount of queried and retrieved data going threw the network. Yes a web app has to download the UI and other data associated with it but when was the last time you've seen a really detailed, beautified corporate web app, in most cases were talking less then 300kb for an average page. Personally speaking as a manager, if it was any bigger then that I would have the person who wrote it go back and remove that stupid Giff of the bouncing question mark.

 

Edit: I also realize that web browsers aren't as efficient with memory management as a native app could be and this has presented problems when displaying large amounts of data but small workarounds like doing the actual calculations in SQL and then exporting the data into a PDF is  a manageable solution to this problem. There are upsides and downsides to everything but to be honest an iPad with only 1GB of RAM would also fall into a same problem. This needs to be addressed by Apple, immediately.


Edited by Relic - 7/27/14 at 7:58pm
When I looked up "Ninjas" in Thesaurus.com, it said "Ninja's can't be found" Well played Ninjas, well played.
Reply
When I looked up "Ninjas" in Thesaurus.com, it said "Ninja's can't be found" Well played Ninjas, well played.
Reply
post #63 of 73
Quote:
Originally Posted by Dick Applebaum View Post


I suspect they will -- and for Android, too!

 

Cool, then I guess I have some studying to do. I have to apologize about last night. I'm not feeling to well and I kind of glanced over the part about your wife dying. Let me just say how sorry I am that has happened to you. One of my greatest fears is not dying myself but leaving my husband and two children alone in the world. I know it's a selfish thing to believe that they won't be fine without me but I truly believe when you start a family you give a part of yourself to them and when one leaves you never get that part back. So although no words can really help to ease the loss you bear, just know that you are very close in every thought and prayer.

 

“If ever there is tomorrow when we're not together...there is something you must always remember. You are braver than you believe, stronger than you seem, and smarter than you think, but the most important thing is, even if we're apart...I'll always be with you.” -(Winnie the Pooh)

When I looked up "Ninjas" in Thesaurus.com, it said "Ninja's can't be found" Well played Ninjas, well played.
Reply
When I looked up "Ninjas" in Thesaurus.com, it said "Ninja's can't be found" Well played Ninjas, well played.
Reply
post #64 of 73
Quote:
Originally Posted by Relic View Post

Quote:
Originally Posted by Dick Applebaum View Post

I suspect they will -- and for Android, too!

Cool, then I guess I have some studying to do. I have to apologize about last night. I'm not feeling to well and I kind of glanced over the part about your wife dying. Let me just say how sorry I am that has happened to you. One of my greatest fears is not dying myself but leaving my husband and two children alone in the world. I know it's a selfish thing to believe that they won't be fine without me but I truly believe when you start a family you give a part of yourself to them and when one leaves you never get that part back. So although no words can really help to ease the loss you bear, just know that you are very close in every thought and prayer.

“If ever there is tomorrow when we're not together...there is something you must always remember. You are braver than you believe, stronger than you seem, and smarter than you think, but the most important thing is, even if we're apart...I'll always be with you.” -(Winnie the Pooh)

Thanks for that -- simple honesty ...

I've added it to the remembrances I've jotted down over time -- it gives me great comfort to review them when things are going wrong.


Native American Prayer

I give you this one thought to keep -
I am with you still - I do not sleep.
I am a thousand winds that blow,
I am the diamond glints on snow,
I am the sunlight on ripened grain,
I am the gentle autumn rain.
When you awaken in the morning’s hush,
I am the swift, uplifting rush
of quiet birds in circled flight.
I am the soft stars that shine at night.
Do not think of me as gone -
I am with you still - in each new dawn.
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
post #65 of 73
Quote:
Originally Posted by Relic View Post

One of my greatest fears is not dying myself but leaving my husband and two children alone in the world.

Then again, they are able to deal with it since you are the one that gives them the strength they need.

I feel for you. Take care Relic.
Send from my iPhone. Excuse brevity and auto-corrupt.
Reply
Send from my iPhone. Excuse brevity and auto-corrupt.
Reply
post #66 of 73
Quote:
Originally Posted by Relic View Post

Quote:
Originally Posted by Dick Applebaum View Post

Yes, but the HTML 5 solution uses a lot of bandwidth -- sending down the wire:
  • verbose CSS
  • verbose Javascript
  • verbose XML or JSON (usually as web services)
  • verbose HTML
  • images
  • links
  • cookies
  • multiple connections


Paraphrasing US Senator, rtd Fritx Hollings:


"Day's a whole lotta' bandwidth consuming' goin' on out dare"



Now, off to have some raclettes 1biggrin.gif

Actually your network traffic would be almost exactly the same if you were using an native application to access a database or web interface. I think your assuming that just because an app is nativity installed on a device it doesn't have the need to access it's networked data as often. Unless programmed specifically to cache it's data, which is rare as data changes constantly there will still be the same amount of queried and retrieved data going threw the network. Yes a web app has to download the UI and other data associated with it but when was the last time you've seen a really detailed, beautified corporate web app, in most cases were talking less then 300kb for an average page. Personally speaking as a manager, if it was any bigger then that I would have the person who wrote it go back and remove that stupid Giff of the bouncing question mark.

Edit: I also realize that web browsers aren't as efficient with memory management as a native app could be and this has presented problems when displaying large amounts of data but small workarounds like doing the actual calculations in SQL and then exporting the data into a PDF is  a manageable solution to this problem. There are upsides and downsides to everything but to be honest an iPad with only 1GB of RAM would also fall into a same problem. This needs to be addressed by Apple, immediately.

Here's a real-life example of a sophisticated client-server app that I recently beta tested. They were doing things today, that we'd never do back in 1997 with a 4800 baud modem.

The app is a business app that is roughly analogous to a multiplayer game -- where each player has a location, some assets, and status. Whenever a player changes anything, his complete status is sent to the server where a db is updated and the updated status of all players is pushed to each active player.

I put a sniffer on the line to see what was happening.

When a player with less than 50 assets loaded a gun (or grabbed a sword) here is the traffic:
  • a cookie of about 1K
  • metadata of about 400K characters -- a JSON packet describing the status of all his assets.

That's quite a bit of overhead for just posting a simple change.

But then the server posts the response to each active user:
  • 3 cookies, each about 1K
  • the entire [refreshed] HTML page to completely replace the screen/window content -- in my example about 16K


So, altogether there was a handshake, 400 characters of actual data, 4 cookies, and an updated HTML page -- about 19K sent each active user -- just to post a simple status change.

Rinse and repeat!

To be nice, this is a bandwidth hog which scales very poorly!

Obvious improvements would be to put some intelligence in the client to:
  • only send a token, e.g User ID and timestamp -- no need for a 1K cookie
  • only send the changed asset number and status -- no need to encode all assets into a large JSON packet

On the server side, the app would recognize the token (UserID and TimeStamp) plus the asset# and status, update the database -- then generate minimal push packets to send to each active user (based on their last Token).

Back on the clients side -- each would:
  • receive a new token
  • receive a packet containing only those players' assets' that had changed since the last update (based on
token)

There would be no cookies, no JSON, no deserialization, no retransmission/regeneration of the entire HTML page (HTML. CSS, JavaScript, etc) -- the client app would merely apply the status changes to the existing HTML page.

Typically, each client would receive < 50 characters for each other active player who had changed something since the last refresh of this user.

By adding a little intelligence, we now have a system that performs well, present's current data, is light on bandwidth requirements and scales beautifully.
Edited by Dick Applebaum - 7/28/14 at 1:53am
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
post #67 of 73
Quote:
Originally Posted by PhilBoogie View Post

Quote:
Originally Posted by Relic View Post

One of my greatest fears is not dying myself but leaving my husband and two children alone in the world.

Then again, they are able to deal with it since you are the one that gives them the strength they need.

I feel for you. Take care Relic.

^^^ This!
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
post #68 of 73
From Ken Burns' Civil War series:

A week before the battle of Bull Run, Sullivan Ballou, a major in the 2nd Rhode Island Volunteers, wrote home to his wife, Sarah, in Smithfield.

My very dear Sarah:

The indications are very strong that we shall move in a few days - perhaps tomorrow. Lest I should not be able to write you again, I feel impelled to write lines that may fall under your eye when I shall be no more.

Sarah, my love for you is deathless, it seems to bind me with mighty cables that nothing but Omnipotence can break; and yet my love of Country comes over me like a strong wind and bears me irresistibly with all those chains to the battlefield.

The memory of all the blissful moments I have enjoyed with you come crowding over me, and I feel most deeply grateful to God, and you, that I have enjoyed them for so long. And how hard it is for me to give them up and burn to ashes the hopes of future years, when God willing, we might still have lived and loved together and seen our boys, grown up to honorable manhood, around us.

If I do not return, my dear Sarah, never forget how much I loved you, nor that when my last breath escapes me on the battlefield, it will whisper your name.

Forgive my many faults, and the many pains I have caused you. How thoughtless, how foolish I have sometimes been!

But, O Sarah! If the dead can come back to this earth and flit unseen around those they love, I shall always be with you; in the brightest day and in the darkest night -- always, always; and when the soft breeze fans your cheek - it shall be my breath; or the cool air, your throbbing temple - it shall be my spirit passing by.

Sarah, do not mourn me dead; think I am gone and wait for me, for we shall meet again.

Sullivan

Sullivan Ballou was killed a week later at the first Battle of Bull Run.
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
post #69 of 73
Quote:
Originally Posted by Relic View Post

Web applications are defiantly the present and future

I think that's true for enterprise apps for the most part but not consumer apps nor apps that big companies make their revenue from. Microsoft for example would never develop Office in a web-app suitable for deployment except in a way similar to Apple's iWork online or Google docs where the customer has to log onto a server.

I'd say the vast majority of apps in future will be developed the way mobile apps are now and deployed through an app store and some enterprises are developing and deploying internal native apps. That's why Apple has that exception for corporations to be allowed to distribute apps:

http://www.apple.com/iphone/business/profiles/

Swift will most definitely (defiantly as you put it) be more efficient for developing these custom internal apps if they are basic enough. They could of course be using 3rd party SDKs that work cross-platform to allow easy deployment to other mobile devices but if the code is minimal or they stick with iOS across their company, they can have it maintained in Swift.

Offline apps will be needed in many situations for speed and where a secure connection can't be maintained.
post #70 of 73
Quote:
Originally Posted by Relic View Post

Web applications are defiantly the present and future, I think I mentioned this before but when I was healthier and working I was employed by the largest bank in Switzerland. I was the managing director of internal programming, though we utilized compiled applications for specialized solutions such as our our trading platform the bulk of our applications were web driven. It's exactly the same situation in almost every company, in every field. Even the applications that ran specifically on a tablet, such as the iPad were for the most part web driven.
[ ... ]
Quote:
Originally Posted by Relic View Post

[ ... ]
it's all about the output in the end. For the most part Enterprise apps are data entry, data retrieval, reports and calculations, things that can be accomplished with a web app and there isn't much that can't be done with HTML5, PHP/Python/Ruby and a Oracle/MySQL/PostgreSQL database.
Quote:
Originally Posted by Marvin View Post

Quote:
Originally Posted by Relic View Post

Web applications are defiantly the present and future

I think that's true for enterprise apps for the most part but not consumer apps nor apps that big companies make their revenue from. Microsoft for example would never develop Office in a web-app suitable for deployment except in a way similar to Apple's iWork online or Google docs where the customer has to log onto a server.
[ ... ]
Quote:
Originally Posted by Relic View Post

Actually your network traffic would be almost exactly the same if you were using an native application to access a database or web interface. I think your assuming that just because an app is nativity installed on a device it doesn't have the need to access it's networked data as often. Unless programmed specifically to cache it's data, which is rare as data changes constantly there will still be the same amount of queried and retrieved data going threw the network. Yes a web app has to download the UI and other data associated with it but when was the last time you've seen a really detailed, beautified corporate web app, in most cases were talking less then 300kb for an average page. Personally speaking as a manager, if it was any bigger then that I would have the person who wrote it go back and remove that stupid Giff of the bouncing question mark.
[ ... ]

First, apologies for my selective quoting and clipping -- I tried to preserve the original context ...

I have some questions about current enterprise apps for mobile -- whether smart phones, tablets or mobile computers.

@Relic and @Marvin -- you both seem to have current or recent experience in this area ... but anyone else with enterprise IT experience, feel free to enlighten -- I really do want to understand this.

Question 1:
From the posts quoted above, it appears that most current enterprise apps for mobile are web apps ... Is this true?

Question 2:
I get the impression that most future enterprise apps for mobile will be web apps ... Is this true?

Question 3:
If there is a typical web enterprise app for mobile would it involve:
  • a random inquiry/response by the user
  • a user in session with the enterprise for a period of time
  • multiple users collaborating with each other and the enterprise
  • push notifications sent from the enterprise to the user
  • the enterprise monitoring the location or status of the users
  • a SWAG estimate of the % for each of the above

Question 4:
Is the user of the typical web enterprise app for mobile connected by:
  • WiFi
  • cellular?
  • a SWAG estimate of the % for each of the above


TIA, for the education of Dick Applebaum ...

What are your tuition/consulting fees 1wink.gif
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
post #71 of 73
Quote:
Originally Posted by Dick Applebaum View Post

From the posts quoted above, it appears that most current enterprise apps for mobile are web apps ... Is this true?

I doubt you'd be able to assess that for certain as these things are internal in private companies but I'd expect that a significant amount of enterprise apps are web apps. But what counts as a web app? A website is basically a web app so a private portal accessed from a mobile device would qualify. The important part of the description of a web app is that it's about data. If you were developing a game for example, it's more creative content. In business, it's about sales data that isn't internal to the app itself. All this sales data is being fed into databases that are independent of apps. If you look at the Procter and Gamble business case on Apple's site:

http://www.apple.com/iphone/business/profiles/pg/#video-procter-and-gamble

they have 25,000 iOS devices. That's pretty substantial in a company with 121,000 employees. In the video you can see the apps. They have 50 internal apps for iOS. Some of them are labelled as portals so these could be developed as web apps or native but the app itself isn't doing much. To a company like that, it's not important one way or the other as their turnaround times are fast:

"We’ve found the iOS platform to be very secure and reliable. And the development process is pretty straightforward; we can turn apps around in four to six weeks."

All the portal apps are doing is accessing the databases so they are very lightweight. Some of their apps are definitely native like the spreadsheet app as they have more complex controls. A few of them are simply making data queries. P&G uses Sybase for their enterprise data:

http://sybaseblog.com/tag/oracle/

This can be accessed natively or through web technology:

http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc01217.0200/doc/html/apr1274488646262.html
http://www.sap.com/pc/tech/mobile/software/solutions/platform/build-apps.html

"Integrate with native, HTML 5, hybrid, metadata-driven, mobile Web, and SMS app architectures"

All those business cases on Apple's site are interesting to watch ( http://www.apple.com/iphone/business/profiles/ ), here's one with GE:

http://www.apple.com/iphone/business/profiles/ge/#video-ge

They show native development in the iOS SDK, saying it takes just a week to deployment and they have their own app store.
Quote:
Originally Posted by Dick Applebaum View Post

I get the impression that most future enterprise apps for mobile will be web apps ... Is this true?

The heavy part of most enterprise apps is the back-end that runs everything, that's in the cloud. The apps are often just lightweight front-ends. Facebook tried to use HTML 5 for their app and they eventually determined that it was a waste of time and reverted to native. Like I say, for huge companies, hiring a few full-time developers to maintain a native lightweight app for each platform is a non-issue.

I don't think you could say what's right for each major company. I think mobile has shown people how native apps can be superior to web apps while being just as accessible and this is because of Apple. Their app deployment is as simple as tap to install, click the cross to delete. That is so far removed from the traditional Windows installers with dependencies routine that is a maintenance headache. Even older mobile devices like Palm didn't get the app deployment that simple.

We're only 7 years into Apple's mobile revolution and big business takes a while to react. I think web apps made sense to get away from the Windows style app deployment but native has its advantages. Web apps have advantages too and don't need Apple's approval for deployment or setting up enterprise deployment.

Relic likes to put a damper on everything that Apple does. I think Swift is a great move for Apple and clearly big companies like P&G have invested in Objective-C developed apps. Migrating to Swift will make their native development simpler. I expect them to similarly use web apps where it makes sense.

I think the future of app development is native (development can be done in a cross-platform language though) and I think web technology will be relegated to basic information delivery. One advantage with native when it comes to data is that the client behaves like the server. Web apps can't query databases directly, the logic has to run on a server first. Native apps will always be more powerful.
post #72 of 73
Quote:
Originally Posted by Marvin View Post

Quote:
Originally Posted by Dick Applebaum View Post

From the posts quoted above, it appears that most current enterprise apps for mobile are web apps ... Is this true?

I doubt you'd be able to assess that for certain as these things are internal in private companies but I'd expect that a significant amount of enterprise apps are web apps. But what counts as a web app? A website is basically a web app so a private portal accessed from a mobile device would qualify. The important part of the description of a web app is that it's about data. If you were developing a game for example, it's more creative content. In business, it's about sales data that isn't internal to the app itself. All this sales data is being fed into databases that are independent of apps. If you look at the Procter and Gamble business case on Apple's site:

http://www.apple.com/iphone/business/profiles/pg/#video-procter-and-gamble

Wow! Great video -- they're not selling' soap the way they did in the 1980s ...

You can easily see the native apps -- the executive spreadsheet, the taking pictures of, and rearranging store shelves ...

Quote:

they have 25,000 iOS devices. That's pretty substantial in a company with 121,000 employees. In the video you can see the apps. They have 50 internal apps for iOS. Some of them are labelled as portals so these could be developed as web apps or native but the app itself isn't doing much. To a company like that, it's not important one way or the other as their turnaround times are fast:

"We’ve found the iOS platform to be very secure and reliable. And the development process is pretty straightforward; we can turn apps around in four to six weeks."

All the portal apps are doing is accessing the databases so they are very lightweight. Some of their apps are definitely native like the spreadsheet app as they have more complex controls. A few of them are simply making data queries. P&G uses Sybase for their enterprise data:

http://sybaseblog.com/tag/oracle/

This can be accessed natively or through web technology:

http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc01217.0200/doc/html/apr1274488646262.html
http://www.sap.com/pc/tech/mobile/software/solutions/platform/build-apps.html

"Integrate with native, HTML 5, hybrid, metadata-driven, mobile Web, and SMS app architectures"

Ahh, yes ... Sybase ... Sybase was the first major db to be ported to OS X -- I was a beta tester. FWIW, Sybase was almost identical with MS DB-Server ... the two companies collaborated and went their separate ways. Back then, Sybase was much cheaper to deploy ...

Quote:

All those business cases on Apple's site are interesting to watch ( http://www.apple.com/iphone/business/profiles/ ), here's one with GE:

http://www.apple.com/iphone/business/profiles/ge/#video-ge

They show native development in the iOS SDK, saying it takes just a week to deployment and they have their own app store.

Yes! and the 1 week from whiteboard design of an app -- to a working prototype. When I was doing web development (indie) -- I used ColdFusion. One of the major reasons is that I could easily throw together a prototype db and app and demo it (over the phone) to a potential client.

The advances in XCode (Storyboards) and Swift (Playgrounds) makes it fairly easy to prototype a native app in days , if not hours.

Quote:
Quote:
Originally Posted by Dick Applebaum View Post

I get the impression that most future enterprise apps for mobile will be web apps ... Is this true?

The heavy part of most enterprise apps is the back-end that runs everything, that's in the cloud. The apps are often just lightweight front-ends. Facebook tried to use HTML 5 for their app and they eventually determined that it was a waste of time and reverted to native. Like I say, for huge companies, hiring a few full-time developers to maintain a native lightweight app for each platform is a non-issue.

I don't think you could say what's right for each major company. I think mobile has shown people how native apps can be superior to web apps while being just as accessible and this is because of Apple. Their app deployment is as simple as tap to install, click the cross to delete. That is so far removed from the traditional Windows installers with dependencies routine that is a maintenance headache. Even older mobile devices like Palm didn't get the app deployment that simple.

We're only 7 years into Apple's mobile revolution and big business takes a while to react. I think web apps made sense to get away from the Windows style app deployment but native has its advantages. Web apps have advantages too and don't need Apple's approval for deployment or setting up enterprise deployment.

Interesting assessment!

Quote:

Relic likes to put a damper on everything that Apple does.

Yeah, but she makes you evaluate and justify/defend your positions -- I find it quite worthwhile

Quote:

I think Swift is a great move for Apple and clearly big companies like P&G have invested in Objective-C developed apps. Migrating to Swift will make their native development simpler. I expect them to similarly use web apps where it makes sense.

I think the future of app development is native (development can be done in a cross-platform language though) and I think web technology will be relegated to basic information delivery. One advantage with native when it comes to data is that the client behaves like the server. Web apps can't query databases directly, the logic has to run on a server first. Native apps will always be more powerful.

"when it comes to data is that the client behaves like the server"

Ha! that's what low-level BLE does -- makes it hard to 'splain vis-a-vis iBeacons.

The way I interpret your last paragraph is that the bulk of future mobile apps will be native -- and the web will, essentially, be gathering and dispensing data with web services.

I think that you are probably correct.

As to cross platform development -- I think that the Advantages of Swift are so compelling that it will become the development language of choice -- including mobile, desktop and backend servers. I strongly believe that Swift development and deployment will be available on all major platforms -- when the timing is right!

Thanks @Marvin for the well-considered response!
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
post #73 of 73
Some more questions for @Relic, @Marvin -- or anyone with current experience in enterprise use of cellular:


Question 1
Does enterprise pay for cellular data with a monthly charge for the device and a charge for data?

I did some surfing and found a billing structure for enterprise similar to personal/family billing.

(I could find no shared data plans in these offerings -- similar to some family plans.)

For example, T-Mobile enterprise plan for 6 - 6,000 users charges:
  • $20 per line including 1 GB of 4G data (unlimited 3G data after that)
  • 3 GB 4G data @ $10
  • 5 GB 4G data @ $20
  • Unlimited 4G data @ $30


As I read these figures, an enterprise with 4,000 lines would spend $120,000 per month for unlimited 4G data (excluding taxes and fees)

Or, if they could get by -- it would cost $40,000 per month for 3GB of 4G data per line -- a savings of $80,000 per month..


Question 2
Is it true that large enterprises with many thousands of mobile devices have special cellular contracts, including shared data?

Question 3
If so, does the enterprise pay based on actual data usage?


So, what if you walked into the office of the IT VP and said: "Would you be interested in saving $960,000 ($.96 Million) per year on your cellular data budget?"

What do you think his answer would be?

Likely, "Yes! How?"

Your answer might be something like:

"Based on an impromptu study, I found that our mobile apps consume cellular data as follows:
  • 70% downloading static web pages to present the data
  • 30% downloading dynamic, current data

If we recode those web apps as native device apps -- we can eliminate 70% of our mobile data charges!

Boom!"



The best plan I could find in the US is from T-Mobile:




ATT has a similar offering, though less flexible and more expensive.

"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: iPad
  • Apple Inc's new Swift language a "huge leap forward for iOS ecosystem," offers "enormous opportunity" with IBM in enterprise
AppleInsider › Forums › Mobile › iPad › Apple Inc's new Swift language a "huge leap forward for iOS ecosystem," offers "enormous opportunity" with IBM in enterprise