Apple Inc's new Swift language a "huge leap forward for iOS ecosystem," offers "enormous opportunity

124»

Comments

  • Reply 61 of 72
    relicrelic Posts: 4,735member
    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 image

     

    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.

  • Reply 62 of 72
    relicrelic Posts: 4,735member
    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)

  • Reply 63 of 72
    dick applebaumdick applebaum Posts: 12,527member
    relic wrote: »
    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.
  • Reply 64 of 72
    philboogiephilboogie Posts: 7,675member
    relic wrote: »
    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.
  • Reply 65 of 72
    dick applebaumdick applebaum Posts: 12,527member
    relic wrote: »
    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 :D

    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.
  • Reply 66 of 72
    dick applebaumdick applebaum Posts: 12,527member
    philboogie wrote: »
    relic wrote: »
    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!
  • Reply 67 of 72
    dick applebaumdick applebaum Posts: 12,527member
    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.
  • Reply 68 of 72
    MarvinMarvin Posts: 15,309moderator
    relic wrote: »
    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.
  • Reply 69 of 72
    relic wrote: »
    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.
    [ ... ]
    relic wrote: »
    [ ... ]
    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.
    Marvin wrote: »
    relic wrote: »
    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.
    [ ... ]
    relic wrote: »
    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 ;)
  • Reply 70 of 72
    MarvinMarvin Posts: 15,309moderator
    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.
    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.
  • Reply 71 of 72
    dick applebaumdick applebaum Posts: 12,527member
    Marvin wrote: »
    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 ...


    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 ...


    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.

    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!


    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


    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!
  • Reply 72 of 72
    Some more questions for @Relic, @Marvin -- or anyone with current experience in enterprise use of cellular:


    [B][U]Question 1[/U][/B]
    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:

    [LIST]
    [*] $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
    [*]
    [/LIST]


    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..


    [B][U]Question 2[/U][/B]
    Is it true that large enterprises with many thousands of mobile devices have special cellular contracts, including [I]shared data?[/I]

    [B][U]Question 3[/U][/B]
    If so, does the enterprise pay based on [I]actual data usage?[/I]


    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:
    [LIST]
    [*] 70% downloading static web pages to present the data
    [*] 30% downloading dynamic, current data
    [*]
    [/LIST]

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

    Boom!"



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

    [IMG ALT=""]http://forums.appleinsider.com/content/type/61/id/46396/width/500/height/1000[/IMG]


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

    [IMG ALT=""]http://forums.appleinsider.com/content/type/61/id/46394/width/500/height/1000[/IMG]
Sign In or Register to comment.