>1/ From
https://developer.apple.com/app-store/review/guidelines/: "Apps that are not very useful, unique, are simply web sites bundled as Apps, or do not provide any lasting entertainment value may be rejected" - Hope business app can soon meet these requirements
Yup that's the issue and I think that's actually a sensible one. If your app just runs as a Web app then people can run it fine in the browser (although that has a usability bias for most users as they look for apps in the store first). Apps need to have a somewhat different experience and whenever possible should be able to run offline without connectivity - especially for business apps.
I talked about the wide host of issues that Mobile Web on its own has (unfortunately):
The broken Promise of the Mobile Web"I honestly wish that we could move into a world where 'mobile apps' aren't necessary and we could just use the Web - and I think it will happen evenutlaly - but we're still a long way off from that now.
+++ Rick ---
>Thanks Rick for sharing your experience, much clearer now ...
>
>Digged a little more into this issue ... Found clear resources:
http://www.awesome-robot.com/article/PhoneGap_and_the_Apple_Store/,
https://developer.apple.com/app-store/review/>
>Lessons learned:
>
>1/ From
https://developer.apple.com/app-store/review/guidelines/: "Apps that are not very useful, unique, are simply web sites bundled as Apps, or do not provide any lasting entertainment value may be rejected" - Hope business app can soon meet these requirements
>
>2/ Better use a CSS framework to meet the UI requirements (standardization)
>
>
>>The Apple Web Store has strict rules about not just repackaging a Web app to run inside of a WebView control. Applications that don't fit some guidelines and cannot start up locally without an internet connection are typically rejected (there are some exceptions for some of the major corporate sites) but it's a known issue. The whole approval process is quite strict and has many requirements that a pure server hosted app generally cannot provide.
>>
>>Like I said a Web app is not a mobile app per se. There's more to it: Device integration to the hardware and software APIs where that makes sense. Pure server side applications just look wrong in app format and as mentioned above are very likely to be rejected in any app store. I've been through this with a few customers who have built with Cordova and have actually created complex apps that included only some part of web hosted content and they got rejected for it - we had to rewrite that code with pure Javascript code that lives locally on the device and wasn't server hosted.
>>
>>I'm just trying to set the right expectations here. It's not as simple as having an index page that links to a Web site and off you go...
>>
>>There are plenty of ways that you CAN use VFP in combination in this environment: as a backend service to a pure JavaScript front end application that runs on device.
>>
>>+++ Rick ---
>>
>>>Make a long term decision requires a long term perspective.
>>>
>>>No idea of Rick's definition of a 'good web/mobile app'; to me it's an app that fulfills the user's and the editor's needs.
>>>
>>>U - From a
user's standpoint, the needs are (ordered by decreasing intensity):
>>>(1)
third parties: safely expose parts of business apps to customers, suppliers, ...: billing, payment, order entry, account reconciling, ...
>>>(2)
mobility: sales and after-sales employees need a safe, no-brainer access to business data when out of office
>>>(3)
BYOD: an expanding movement where employees use their personal device in the corporate work space.
>>>
>>>From this standpoint terminals are mainly: (1) remote desktop computer, (2) tablets and laptops, (3) anything
>>>
>>>Need for smartphone access to business apps: almost none today, increasing the future.
>>>
>>>E - A
S/W editor's needs are:
>>>(1)
features: fulfill the above user needs
>>>(2)
cost: deliver these features with similar license fees
>>>(3)
maintenance: cut the installation and support costs
>>>(3)
SAAS: on-line S/W sales, on line demos, etc.
>>>
>>>Solutions depends on the company and market size:
>>>
>>>
xamarin:
>>>desktop will stick around for U(1)
>>>requires server-side development just like web-based apps
>>>- investing on native mobile business apps is premature
>>>
>>>
HTML:
>>>universal
>>>versatile
>>>powerful UI
>>>- optimal choice
>>>
>>>> And running in Cordova with server written pages - while that might work for development, it'll almost certainly be rejected by the app stores.
>>>
>>>1/ Of course not! PhoneGap and Cordova would not even exist if you could not deploy your app on the app store...
>>>Any OS needs apps to grow - as Windows teached us - the interest of Apple, Android and others is to expand their app store, not to reject apps;
http://fr.slideshare.net/DrakeEmko/app-stores-cordova-get-excited>>>
>>>2/ hybrid applications have been in app stores for years; eg. LinkedIn mobile application was hybrid until recently:
http://venturebeat.com/2013/04/17/linkedin-mobile-web-breakup/>>>
>>>> And - if you're building for phones - using FoxPro forms would be the last thing I'd want to do build a good looking mobile UI that feels like a native mobile application. Mobile apps have unique constraints that and in my experience need explicit tweaking to work properly in multiple resolutions.
>>>
>>>1/ No business user really expects to have a facebook-like mobile application, don't even care to have a smartphone app
>>>users expect to access their usual business application from a tablet with comfortable response time, adding some CSS / JS effects is fine.
>>>
>>>2/ Mobile users are very happy with a regular business application that they can access from anywhere using a browser:
>>>eg. a FoxInCloud client (ERP editor) with app. 200 clients has completely moved its support application to the FoxInCloud Web-based application: customers open tickets on the web and technicians organize their work based on the same application :
https://www.youtube.com/watch?v=nr1K47lVsIA>>>
>>>3/ FoxInCloud splits the VFP forms into separate HTML, CSS and JavaScript:
>>>- HTML reflects the controls structure, depending mainly on the data structure: you'll need the same controls for the same data across any dev. tool: textbox, checkbox, radio, etc...
>>>- CSS determines how objects appear: FoxInCloud follows the original form layout by default, dev. can override this in whatever manner he sees fit, use widgets such as date picker, graphical buttons, etc., change the size, use relative positionning, media queries, etc. - no constraints whatsever to morph the display
>>>- JS wires the user interaction using the equivalent of bindevent (attachEvent, addEventListener, etc.): again developer can either use the VFP user interaction as default, implement additional event handlers or replace by custom handlers.
>>>
>>>Using a VFP form just brings the benefit of using the VFP code on the server side, without any constraints on the UI - keeping the VFP default is fine, upgrading to a nicer look and feel is just fine also.
>>>
>>>
>>>
>>>>Couple of things.
>>>>
>>>>A mobile WEB application is not a mobile application. Those are two different things. No matter what you do you will not be able to write a mobile app that runs on a mobile phone and is app store hosted.
>>>>
>>>>I've written a bit about how I WOULD LOVE for the mobile Web to be a viable platform for mobile apps but the reality is that there are lots of problems with the mobile Web as mobile platform:
>>>>
>>>>
The broken Promise of the Mobile Web>>>>
>>>>There's a lot more to building a mobile APP than just providing a UI that fits into a small screen.
>>>>
>>>>And running in Cordova with server written pages - while that might work for development, it'll almost certainly be rejected by the app stores.
>>>>
>>>>And - if you're building for phones - using FoxPro forms would be the last thing I'd want to do build a good looking mobile UI that feels like a native mobile application. Mobile apps have unique constraints that and in my experience need explicit tweaking to work properly in multiple resolutions.
>>>>
>>>>In a way it's simpler to build Mobile apps using HTML, but to write *good* mobile apps that look nice and behave like mobile apps and not like desktop apps si actually very difficult even if you have full control over the UI.
>>>>
>>>>+++ Rick ---
>>>>
>>>>>Hi Metin,
>>>>>
>>>>>Once in a while, I'll disagree with Rich and Craig ... ;)
>>>>>
>>>>>Yes,
you can start developing mobile web application with VFP using FoxinCloud - and move afterwards to some other server technology.
>>>>>
>>>>>Let me explain you why and how in 6 simple steps...
>>>>>
>>>>>1. Using FoxInCloud, you adapt your existing VFP application to the Web (less than 1%) - you have your first foot in the Web, your client appreciate.
>>>>>
>>>>>2. Using CSS, you adapt your HTML/CSS/JS front-end generated by FoxInCloud to your target devices (iPad/iPhone, etc.)
>>>>>
>>>>>3. Using Cordova, you build hybrid Web applications using your VFP code on the server and the adapted HTML/CSS/JS that FoxInCloud provides
>>>>>
>>>>>4. If not already, you move your data to a SQL database
>>>>>
>>>>>5. You select your favorite server-side platform (php, .net, Java, ruby, etc.) and develop the transaction equivalent to what your VFP application currently does
>>>>>
>>>>>6. Using JavaScript, you rewire the events from FoxInCloud to your new Applicaiton Server (at that point you have your FoxinCloud Application Server and your xxx Application Server server working side by side against the same database)
>>>>>
>>>>>
>>>>>This process safely takes you from a 100% VFP/desktop offering to a 100% Web-based offering without any change on the user side: your UI is stable, you don't need to train anyone, users can gently 'slide' from desktop to the web.
>>>>>
>>>>>> No rewrite, no migration, no brutal change, progressive learning, back-up solution, no dual maintenance, etc.
>>>>>
>>>>>
http://foxincloud.com/demotest/ - FoxInCloud Application optimized for iPhone using CSS
>>>>>
http://foxincloud.com/tutotest/ - Overview of FoxInCloud capabilities and adaptations
