I will soon be writing a native iPhone app for my web site. The web site is already mobile optimised so could potentially just sit in a UIWebView. How does the Facebook app work? Does it do something similar?
If I did use a UIWebView then how would I store user credentials so they don't have to log in every time and how would they upload photos? These are my two main requirements.
The facebook app is going to be a native app. It is different from the mobile website.
There are two things you can do here. If you're going to make your native app just a UIWebView then don't bother! You can have an apple icon embedded in your website which will show if a user bookmarks your website on their home screen. To use this use the <link rel="apple-itouch-icon" href="/apple-touch-icon.png" /> code to do it.
The second is make a fully native app. I know the benefits of a UIWebView app, but the negatives are plain to see. UIWebView apps are tacky, nonfunctional and terrible to use. A mobile website is not an app (unless done very well). You will have links to click, pinch and zoom, awful bounce effects on the web view, links that may possibly allow users to navigate away from your mobile website but within your app. Again, unless done cleverly, you will have to provide browser controls on your app which will make it look like a tacky web browser.
My suggestion would be either stick with your website, optimise it for touch based input, make it a really good mobile website, or create a fully functional native application. Remember not all websites need to have an app to go with it. If your app isn't necessary then its merely counter productive to make an app for it. I don't know about anyone else, but I spend more time in my web browser than I do in apps.
With regards to uploading and auth then a) auth should be done already in your website. A UIWebView is just an instance of safari working within your app, so it will be able to get and store cookies and all sorts. I believe these degrade at the end of the app session, however its easy to pass to the objective c and store in an stored preference. b) uploads not going to work even if you put your site in a web view. You will have to (at some point) hand off to an upload screen in your app which is running natively.
I would suggest that you start off with a simple native app. Let the users log in, upload stuff and do other basic stuff - whatever they can't currently do on your mobile website. Then move on to other things as people ask for them, or as you have the time to make them. You don't have to launch your app with a fully functioning version of you website (in fact this would be silly because the only thing they cannot do on your mobile website on their phone is upload stuff). I'm sure people will request features as your product evolves.
I would take a look at PhoneGap, you can get access to native device features through javascript http://phonegap.com/
Related
I have a mobile web app designed as a single place for employees of our company to help them locate various online resources. The app has a lot of in-app content, but also provides links to external partner websites. My issue is a common one with a bit of a twist. I like the way the app looks in standalone mode on an iphone, but am struggling to figure out a solution for keeping the app in stand-alone mode, while also providing the ability to open external links in safari. I know how to keep the app in standalone mode when links are clicked, but when an external link is clicked, one of two problems occurs:
1) If I code the external link to keep it in standalone mode, there is no way to navigate back to my app from the external site as the back button is obviously no longer available.
2) If I code the external link to open in safari, when the user is done with the external link, the session for my app is closed and the user has to go back to their homescreen and re-open it again. (I know I can code it so that they will return to where they were in the session, but this is not the solution I want).
My question is this, is there a way to open external links ON TOP OF a standalone web app session? So that when the external link is closed, the standalone web app session appears?
I've read that I can use AJAX to open external links within the active session, but I don't know how to do this and can't find anything online that explains it well. Any help would be MUCH appreciated.
My app functions fine in safari, but looks SO much better in standalone mode; I would be SO appreciative if anyone can provide a solution. I am also willing to discuss paying someone to help with this as well.
Cheers,
SC
Turn your app into an actual app, not just a web site. You should implement your own web browser in your app using UIWebView. It's very simple. You probably only need a back button and a close button, you don't need a full search/address bar, bookmarks, etc. UIWebView and two buttons will do it.
As soon as you switch apps to Safari you will see the behavior you have described - there's no getting around it. Your only choice is not to exit.
https://developer.apple.com/library/ios/documentation/uikit/reference/UIWebView_Class/Reference/Reference.html
I'm new to mobile programming. Recently my company has looked into creating a specific application for tablets (Android and iOS). So it was assigned to me to develop a thin-client based around using HTML5 for what we need to do.
Essentially the application allows a user to fill in a custom-designed form (which the user can build themselves, or pull down a predefined template from our server). This form is built using HTML5, Javascript, JQuery, etc. Some additional functionality is planned, such as being able to take a picture using the native device and attach it to the form that we send back to our server for storage (once we figure out how to do it in iOS. We've already done it in Android.)
However, I noticed the following on Apple's App Store Guidelines, under the Functionality section. Item 2.12:
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
Can someone explain, or at least direct me to clarification of this when using the UIWebView construct? This application at its core is pretty much just HTML5. While it might have some additional bells and whistles, does this mean that if we try to submit this (when its completed) to Apple, that they will simply reject it out of hand? Implementing the majority of it in HTML5 was done purposely so we wouldn't have to re-code everything from device to device (and we will also embed it in one of our products, so if they want to fill it out on the desktop while in our system, they can.)
Any guidance would be appreciated, or even suggestions of where this question should be asked if SO is not the proper forum for it. Thanks again.
The key in the Appstore guideline is the word "simply":
Apps that are not very useful, unique, are simply web sites bundled as
Apps
If you keep a balance between locally stored and remote HTML content for your webviews Apple would not look at the app as a hollow shell pulling in remote content.
my site is responsive, and it's looking good on Safari on iPhone. But when I browse to my website from my Twitter app on my iPhone, it seems to ignore most of my mobile styling and looks very bad. Is there something I can do to detect if the browser is some kind of mobile app (such as Twitter) and cause the page to load in the default mobile browser instead (Safari, Browser, etc.)?
Edit: I strictly used CSS' max-width media query and targeted HTML5 block elements to change widths into percents. On two navs, I changed the display attribute as necessary.
Turns out it was a caching issue. It loads fine in the Twitter app. Oddly, it didn't before, even after several tries.
To the best of my knowledge, you can't force the site to open in the default mobile browser. The decision whether to open your site in the app's UIWebView or the default Safari browser is made by the Twitter app alone. If the Twitter app was gracious enough to provides any interface for you to choose, it might be possible, but they probably don't. Most app publishers try to keep users inside the app for as long as possible, and throwing them outside to a different app usually goes against this.
Your best bet is probably to try to improve your site's responsiveness to also work inside the Twitter app UIWebView as well (or inside other apps for that matter). If you base your responsiveness on screen width for example (CSS max-width and friends), I assume it should also work inside the Twitter app UIWebView.
The problem you are describing is indeed a very serious and annoying one. UIWebViews inside apps don't implement by default all of Apple's special handlers (that work inside the original Safari). The app maker is expected to implement these manually, and 99% of all apps simply don't do this. It's true for many other apps as well, the Google native search app also opens URLs inside a UIWebView - and sites tend to look lousy there too.
You should also consider filing a bug with Twitter and urge them to improve website compatibility when opened inside their app.
You can't force the user to open the link from a browser from your website. Android WebView is restricted and by default does not allow javascript and other extensions.
You can find more information here: Android WebView VS Phone Browser
I have a client that needed to abandon their very poor native app and needs a temporary solution immediately. They have a mobile optimized website and we'd like to deploy an app in the store to replace the current one, and design it such that as soon as you launch it, it either hosts the site within a web browser control, or just redirects the user to a website in the iPhone Safari app. I realize there are subtle differences between the browser control and the actual Safari browsers.
Are there any tools or products that auto create such simple apps, and are there any problems with getting such simple apps approved by Apple?
Sounds like you want to make a hybrid app.
http://www.cocoacontrols.com/posts/a-primer-on-hybrid-apps-for-ios
Your app could just be a UIWebView that shows the website. It's possible that Apple might reject ithe app if there is nothing to it except a web view -- do some research on that possibility.
My company has an app (iOS and Android), to which the following scenarios applies. I'm trying to help point my engineers and product team in the right direction.
When one of our users clicks on a content link from one of our emails, or Tweets or Facebook posts, and they're on their mobile device, we prompt the user with a link to download our app. This is similar to what many apps do, including LinkedIn (see i.stack.imgur.com/glSgJ.png).
I imagine this is mildly effective of driving awareness and downloads of a native app, for new users who came in from social media and various web sources. However, it is not helpful at all for a user like me who already has the app!
1) clicking "No Thanks" keeps me on the mobile web (when I want to be in the native app), and
2) clicking "Download the App" takes me to iTunes App Store page for an app I already own.
SUPER ANNOYING. As a result, I have to manually open the app, and search for the content in question. I'm guessing most users don't do this. More importantly, depending on the UI/UX of the app, I may never get there!
Again, I know we are handling mobile web visits in the same way many other companies (including LinkedIn) do, but it seems we are leaving a lot of potential native app use on the table. I want our engineers to build that elusive 3rd option, "Open In App".
Spotify and Rdio have solved this very nicely. Here are deep content links (in the case of these companies, to a specific song) for the two apps respectively:
http://open.spotify.com/track/2SldBUTJSK6xz43i8DZ5r2
http://rd.io/x/QF3NK0JKWmk
If you have a moment, first grab the free version of Rdio or Spotify apps. Then, if you open those links above from an iOS device, you will see how nice the experience is, for existing native app users: Rdio has a nice "Tap to open in Rdio" link (http://i.stack.imgur.com/B7PuE.png), and Spotify's link is even more clear, "I have Spotify" (http://i.stack.imgur.com/Q3IV6.png). Both apps also include a link to download the app, for new app users. More importantly, both apps cookie the user: future visits to links (whether from email, Twitter, Facebook, etc) on mobile web automatically open the app, instead of prompting you to choose each time. SUPER CONVENIENT.
Questions:
1) How do they accomplish this? I'm initially only concerned about iOS (on which I tested this), but this same situation should apply to Android.
2) Why aren't more apps doing this? It doesn't seem like rocket science, so am I missing a key reason why this might be a bad idea? Half of my problem is convincing the use case.
3) Why don't I see discussions about this technique? I've searched a ton for an iOS solution. I come up with a lot of discussion about URL registrations (mainly app-to-app), but no one actually referring to the type of scenario I describe (mobile web prompt to open native app).
It seems that with minimal engineering, app developers could dramatically increase native app use, converting from mobile web. :)
Android supports deep linking. Please refer to
http://developer.android.com/training/app-indexing/deep-linking.html
Tapstream's deferred deep links can send users to specific views within apps (iOS only), even when the app isn't yet installed on their device.