iOS 10 has foisted https upon us and totally broken an application I'm developing. The application is partly an RSS reader. The URLs we get from the RSS feeds are often HTTP URLs, both for the sites, and the metadata images. These HTTP URLs are redirected to the https versions when available just fine in safari and SFSafariViewController. However, when using WKWebView, this redirection does not happen. The OS just blocks the non-https load altogether. If I try to hack around the issue by swapping "http" for "https" in the URL, often the sites break as they load their images, CSS and JavaScript from HTTP CDNs and those requests get blocked too. How can I get the same behavior in WKWebView as seen in Safari? Is there a configuration I can set? It seems crazy to me that Apple would make this change and just break clients using WKWebView.
P.S. Facebook is able to work around this somehow. I can't tell if it's a heavily hacked SFSafariViewController or they've somehow made the web view work. Does anyone know how they've accomplished this?
Use NSAllowsArbitraryLoads. The key is still available for use; Apple just wants to make sure you have a good reason to use it. Displaying external content inside your app qualifies as such. Once the Apple ATS rules go into effect, you will need to provide an explanation why you need it, and why NSAllowsArbitraryLoadsInWebContent is not enough. Since you already have answers for that, there should be no problem getting your app pass the review process with NSAllowsArbitraryLoads.
As a note, Apple has postponed ATS requirement and will not go into effect in January 2017.
After digging around in Apple's documentation here I found the new NSAllowsArbitraryLoadsInWebContent key. This fixes the issue for WKWebView, though frustratingly fetching images over http is still problematic. I'll probably end up having to proxy them through my own server.
While you can simply use NSAllowsArbitraryLoads' to globally turn off at transport security, this is not ideal, and will be more likely to be rejected by Apple without hey really rock solid justification.
A better solution, which will provide the correct behavior in both iOS 9 and iOS 10, is to put both NSAllowsArbitraryLoads and NSAllowsArbitraryLoadsInWebContent in your info.plist. Because iOS 9 does not acknowledge the NSAllowsArbitraryLoadsInWebContent, It will honor the NSAllowsArbitraryLoads, effectively turning off at transport security in iOS 9 devices for your app.
In iOS 10, if you include the NSAllowsArbitraryLoadsInWebContent'key, iOS will ignore the NSAllowsArbitraryLoads setting, only disabling app transport security only in web views in your app. This will mean your app is much more secure in iOS 10, which I believe will make apple more likely to except your justification for the use of your app transport security exceptions
Edit: My below answer is incorrect. It does not work for sites which return XSL, for example RSS feeds hosted on feedburner. I was unable to find a solution for this, so unfortunately I am going back to enabling arbitrary loads.
Our app also has a generic RSS reader feature in it. We want to use ATS for better security and to be in compliance with Apple. In addition, disabling it is considered a high risk by many enterprise clients. As such, enabling "Allow Arbitrary Loads" is not a valid option for us.
For now, we've made the best of this by doing two things:
1. Enabling Allow Arbitrary Loads in Web Content. We also have a generic webview which displays customer content.
2. Using a non-visible WKWebView to load an RSS feed, then extracting the HTML from the webpage and parsing the XML. I've created a gist for that here
Somehow, this terrible hack seems to suit our purposes, for now.
It would be great to have a solution that allows you to override transport security at the URL session level.
Related
I have been searching around for a bit and cant find any solution to this question.
I need to run a browser on an iPAD that allows cross-origin policy to be bypassed. This is easily achieved with a windows machine by launching lets say chrome with --disable-web-security I have read that Phonegap allows this but the app is already in place.
Ill take any solution including jailbreak's
I'm not aware of any official ways to do this.
If you rely on cookies, the alternative would be to read every header to every response and manually assign received cookies to different domains (the downside to this is that you must know the other domains to be used beforehand). For handling cookies, check out [NSHTTPCookieStorage sharedHTTPCookieStorage], the default storage for native apps.
I'm planning to implement some app that performs similar functions as some website does. An app should be able to post, get and view some data. Most viewing data is available only after login. Payments. The webservices are .NET asmx XML services.
So, I'm planning to use UIKit, drag and drop some text fiels. For posting the data, I will do some manual input validation, assemble input into a string, post it to the server. Also, some parsing will be done after getting info form a webserver. Now, I haven't done any website app before, so I'm just curious what are the potencial problems that I might run into.
I guess you are asking about potential technical issues. The ones I faced recently working on an app of this type and workarounds are:
Maintaining your session with the server if you are combining native UI screens together with UIWebView's of your website.
XML Parsing can be hairy at times, so JSON is the best option depending on your preference. The other solution is to output XML in the PLIST format which is easier to code against. On the server side PHP has some PLIST generating libraries. Am not aware of what is available on .NET.
On the iOS side the ASIHTTP library helps make it easier to post to websites, particularly when you are using binaries etc.
Depending on your use case you may also consider a pure web based UI version which resides inside a UI webview. If you are planning on going this route JQueryMobile is a pretty good solution for rendering iOS like UIs. This saves you quite a lot of effort on the communicating with the webservice and parsing etc.
Thats all I can think of for now.
Biggest problem might be getting it approved by Apple if they think it should be just a website and not an app. They might cite: "Limited Functionality". see : https://developer.apple.com/appstore/resources/approval/guidelines.html
I can also reccomend www.sudzc.com
Your UI will certainly not be as responsive as a native app.
Your users won't be able to use your app without an Internet connection/flaky connection
You'll have to rebuild all native controllers yourself if you wan't your app to look like a native iPhone app.
You'll have to rely on libraries like PhoneGap to use most of the hardware/non HTML supported functions (like geolocation, camera, etc.)
Etc.
I've got a client that wants to have a paid app providing his video instructional content on iOS, but of course we dont want people simply getting the video content directly without paying for the app.
Is there some simple way of doing this that I'm overlooking? He wants the content streamed so he can add content easily and periodically without app updates.
Perhaps using Youtube but having the videos password protected? Is there a service anyone has used with an appropriate iOS API that anyone has heard of?
I've never done this before, but you could do some kind of token exchange based on the device ID. When the app is first used, register the device ID with the content server, and use that in combination with a salted hash of some kind to identify the device when requesting the media from the server.
I'm considering two options right now.
1- Following this post (roughly) In iOS, how would you programmatically pass a username / password to a secure site and essentially doing a combination of .htaccess for password protection, leveraging robots.txt to prevent search engines from indexing the videos, and obfuscating the video names. I've got to research the password protection of the video directory and how exactly to do that... but it seems the simplest. The downside is the clear text password.
2- A slightly more sophisticated method where I use oAuth to authenticate against but really following the first path, and potentially leveraging http://maniacdev.com/2010/09/new-open-source-oauth-library-for-easy-authentication-on-ios-devices-from-google/ to help in writing the oAuth piece.
a third possibly prohibitively expensive option is to look at the HTTP live streaming in OSX server https://developer.apple.com/streaming/
How do you guys think these options sound? Are there others I'm not considering?
When I implement OAuth in iPhone, I have a dilemma to choose Safari or UIWebView to open the Twitter pages for user authentication?
I write some advantage and disadvantage of both case:
Using UIWebWeb. The disadvantage is users have to enter their credentials in our application. It's maybe risky phishing. The advantage is this approach will not quit our app.
Using Safari for user to authenticate (this approach automatically callbacks to our application) Addvantage: less risky. Disadvantage: have to quit our app
A good reference link about this: http://fireeagle.yahoo.net/developer/documentation/oauth_best_practice
Which approach do you prefer?
Any response is appreciate. Thanks.
The vast, vast majority of users will not understand or care about the distinction. Do whatever makes their lives easier, or--all else being equal--your life easier. And so long as you are trustworthy (you're not phishing or peeking at their credentials, right?), you'll be providing a good experience and not screwing them over. In this case, I'd use the UIWebView.
The guy who did the Pownce iPhone app a couple of years ago sort of publicly debated with himself about this.
His blog doesn't seem to be up anymore, but basically he implemented it the "right" way as far as OAuth is concerned. Instead of entering credentials inside of the app, Safari was launched and they were entered in there, and then a custom iPhone URL was used as the callback to relaunch the Pownce app. Pretty neat, eh?
Some time later, the developer followed up with a comment that a lot of people were downloading the app but not actually using it. His conclusion? That his brilliant OAuth scheme was to blame. Users were confused by Safari launching and being taken out of the app.
To be honest though? I think the fact that the app was for Pownce, a service that nobody used, was to blame.
I have an app in the app store right now that uses the Foursquare API, which supports both Basic HTTP auth and OAuth. I decided to "do the right thing" and use OAuth. The user enters their credentials directly inside of my app. Am I saving their username and password in plain text anywhere? Nope. But could I be? Sure.
It might sound like I'm arguing for both sides here, but what it really comes down to is that it's very unlikely that your users will know or even care about what OAuth is. It's probably just as unlikely that they will even think twice about putting their credentials into your app. OAuth is great (a hell of a lot better than OpenID) but wasn't designed with the iPhone in mind. It's built to work inside of a web browser. I think the Foursquare API docs put it best when talking about their Mobile/Desktop client OAuth scheme (different from what they want you to do for a web app) - "We provide this mechanism under the assumption that if a user has installed your application on their hardware they, trust it enough to pass through their authentication information to foursquare."
I've already implemented this as a drop-in set of classes (open source). Feel free to take a look: http://github.com/bengottlieb/Twitter-OAuth-iPhone
For the best user experience with destop and mobile application, we should use xAuth:
http://docs.google.com/View?id=ddkz8b2q_76d95356mz
As of May 31st, 2017 and onwards, there is no option left. We MUST use Safari, since google now does not support OAuth via UIWebView. Refer this link for more details.
I've been doing mobile app development for a long time (2001?), but the systems we worked with back then were dedicated mobile development environments (Symbian, J2ME, BREW). iPhone SDK is a curious hybrid of Mac OS X and Apple's take on mobile (Cocoa Touch).
But it is missing some stuff that other mobile systems have, IMO. Specifically:
Application background processing
SMS/MMS application routing (send an SMS to my application in the background)
API for accessing phone functions/call history/call interception
I realize that Apple has perfectly valid reasons for releasing the SDK the way they did. I am curious what people on SO think the SDK is missing and how would they go about fixing/adding it, were they an Engineering Product Manager at Apple.
The biggest shortcoming in my opinion is support for separating licensing from distribution.
What I mean by this is that it should be possible to download a trial version of an application and later purchase a license for that application (from an API call inside the application or from the app store). This would make it much easier to try-before-you-buy and get rid of the current duplicates of many applications with 'lite' versions.
I think lack of push notifications for apps is the big thing we're missing right now. With push, you can register your application to perform a task (like getting the most recent data from a web service) even when it's not running, at a time and frequency the OS decides is best. In an ideal world, along with the existing concept of iPhone apps loading quickly and resuming where you last left off, this solves the problem of not running in the background. I know some tasks will be more difficult or maybe impossible with this strategy, but it's still a pretty good compromise between third party applications and the iPhone's limited hardware.
Originally push was scheduled for last September, but it was removed from the beta SDK and not spoken of since then.
API's I'm personally looking for:
Apple80211 as a public API (private, current API is fine if documented)
Access to Volume buttons (semi-accessible via Celestial, private, needs new API)
Access to Calendar (private, API status unknown)
Access to Bluetooth + SPP profile (status unknown)
Access to Camera (directly, API status unknown)
Access to JavaScript runtime (directly, not through UIWebView, API status unknown)
WebKit access that's lower-level than UIWebView (private, current API is fine)
Access to Music Library (private, current API is fine)
Garbage Collection.
CoreData is missing.
You've mentioned some of the big ones - copy & paste (or in fact any way for apps to collaborate) is another huge omission.
It also seems to lack a desktop synch framework (at least if it exists I can't find it).
Language independence and especially lack of scripting is another pet peeve - objective-c is all very well but more languages to choose from would be good.
Inability to dynamically extend apps, via scripts or otherwise, is another big omission. This is partly an SDK/OS issue, partly licensing.
My list ordered by priority:
Mapping abstraction (the MapKit looks awesome), but that would require a new Google Maps TOS
Music library
Camera (photo + video) Access to more
UIViews, Apple designed some pretty nice custom ones for their apps
Better UIWebKit abstraction
The features I see missing that it should have is
Access to SMS
Direct Access to Google Maps App. You should be able have access to this so you could extend your application to use the built in features provided by Google Maps.
Access to the Bluetooth functionality of the phone.
Access to the Calendar. Why not allow access to simply post a calendar event for the user.
Access to Active Sync. It would great if we could directly access this and communicate back to the Exchange Server.
Core Image. They provide Core Animation but Core Image is missing. I hope that this is added to the API soon.
These are some of the features that my clients have access for in the past and are supprised when they are not available.
We definitely miss a Calendar API and SMS access. So many applications could leverage such APIs. The iPhone allows users to have everything in their pocket, but it's almost useless as long as developers cannot leverage this integration in their apps.
A language with proper namespaces.
A limitation that bugs me is lack of access to system features that require root or setuid. For example: opening privileged IP ports.
I'm not sure there is a good solution to this, as long as Apple's policy is to keep the device locked-down.
Allow program to set some kind of local timed event for your application to bring up an alert and launch your app if the user agrees (like any calendar app). You could do that with push notifications but there are many cases I'd hate to have to rely on a whole server infrastructure and network connectivity just to basically do some timed thing.
Some idea of what direction the user is facing. I cannot believe the GPS chip the newer iPhones use are not capable of reporting direction.
I would personally love to see
Access to the CoreTelephony Framework (Currently private). Which allows access to all the phone functions (Especially sending MMS / SMS).
Some sort of ability to run stuff in the background. While push notifications is ok for most things, but it is a bit hard to leverage CoreLocation (i.e. have the app show a notification at a certain location). Of course this would probably need an on/off button or app specific like push is.
animation view which will be reduce developer to make a cool app , of course the core business local still need consider more , but the view layer could more easy to use ....