Im about to release a hybrid app that i have built for iOS and want to know if it "contains encryption" from the point of view of apples export compliance.
Im using multiple UIWebView's to open certain URL's (https://linkName) and for authentication as well. The app does not have a REST API, just web views that load a web page based on the URL. I also use flurry and their iOS SDK for analytics.
Does this mean that it falls under the "Contains Encryption" for apple? Or is it ok to check no for this and submit to the app store.
Related
I am planning to use app link from FBSDK to invite using my iOS app via email.
I know if my iOS app was installed on the device it will be opened when I select the link and handle invite token in URL.
But how about if my app was not installed?
After user install it from App Store can I handle invite token also?
Hope anyone used to work with this scenario can help me.
There are a lot of reasons why what you're trying to do won't come out the way you want it to. Let's dive in...
App Links don't work anymore
Facebook created App Links in 2014 as an open standard to solve the limitations of URI scheme deep links. App Links have two main components:
A set of meta tags to add to the web page destination of a standard http:// link. These tags specify the custom URI scheme location of corresponding content inside the native app, and the behavior that should occur if the app is not installed.
A routing engine for use inside apps that support opening links. This engine checks the destination URL for App Links tags before opening it, and then launches the corresponding app or executes the specified fallback behavior.
App Links were supposed to be an open-source standard to change the world, making app-to-app deep linking simple and universal. Unfortunately Facebook has decided they actually don't want that world (it's much better for them to keep users inside the Facebook app — see Instant Articles if you don't believe me), meaning the App Links standard is essentially dead. It's no longer supported on the iOS Facebook app, and Applinks.org isn't even a separate website now.
App Links were not designed to work with email (or essentially any app except Facebook)
Even if it were still supported by Facebook, the App Links standard has a critical flaw: it requires work by both the origin and destination apps. While the meta tags component saw wide adoption, the only major implementations of the routing engine were in the core Facebook and Messenger apps.
To function as you want, where deep linking can occur from links in emails, the routing engine component would need to be implemented in any email app where your link could possibly be clicked. This was never going to happen for apps like the default iOS Mail app from Apple, or the Gmail app, for example.
App Links had no meaningful support for deferred deep linking
Deferred Deep Linking (Deep Linking refers to using a link to open your app directly to a specific piece of content, and Deferred means that it works even if the app isn't installed first) requires a remote server to close the loop. You can build this yourself, but you really shouldn't for a lot of reasons, not the least of which being you have more important things to do. You'll notice that neither of the two App Links components included a remove server to retain link data through install, so deferred deep linking was never properly supported in the core App Links standard. Facebook ads make use of the partial support for deferred deep linking offered by the FBSDK in conjunction with App Links, but this only works when the link/ad is clicked within a Facebook app and the receiving app has the FBSDK integrated.
Deferred deep linking is tough anyway
Moving on from App Links, deferred deep linking is still complicated. URL schemes don't work, because they always fail with an error if the app isn't installed. Apple's newer Universal Links in iOS 9+ get closer in that they at least don't trigger an error if the app isn't installed, but you'd still have to handle redirecting the user from your website to the App Store. You can't pass context through to the app after install with Universal Links, so you wouldn't be able to send the user to the correct item, and they actually aren't supported in a lot of places.
Deep linking out of email on iOS is very hard
Almost all email links involve some sort of click tracking, which is always implemented as a link wrapping redirect. This isn't technically a problem if the user doesn't have your app installed, but if they do, Universal Links don't work with wrapped links. If you're building it yourself, you'll either need to completely disable click tracking in your emails, or accept that deep links won't work there.
Bottom Line
App Links were never the solution you needed. A free service like Branch.io (full disclosure: they're so awesome I work with them) or Firebase Dynamic Links is what you need. Both services support deferred deep linking, out of Facebook or almost any email app. Branch is more powerful and offers far more features, and works with major email senders to offer a solution for deep linked email (the only one on the market today).
This may sounds crazy but just curious to know how a deep link/ URL schema reaches to an app to open it up in the device. Searched for an article but all contain how to make it work technically which I completely experienced, but could not find one how the handshake works.
If anybody can share if known, much appreciated!
Thanks.
The best information I could find so far on the subject is Wikipedia:
Unlike the Web, where the underlying technology of HTTP and URLs allow
for deep linking by default, enabling deep linking on mobile apps
requires these apps be configured to properly handle a uniform
resource identifier (URI). Just like a URL is an address for a
website, a URI is the address for an app on a mobile device. Examples
of URIs that launch a mobile app:
twitter:// is the iOS URI to launch Twitter’s mobile app
YouTube:// is
the iOS URI to launch YouTube’s mobile app
The format of the URI used
to trigger or deep link an app is often different depending on the
mobile operating system. Android devices work through intents,
BlackBerry 10 devices works through BB10's invocation framework,
Firefox OS devices works through Web Activities, iOS devices works
through the openUrl application method, and Windows Phone 8 devices
works through the UriMapper class.
fb://profile/33138223345 is an example of a mobile deep link. The URI
contains all the information needed to launch directly into a
particular location within an app, in this case the profile with id
'33138223345', i.e. the Wikipedia page, within the Facebook app,
instead of simply launching the Facebook app fb://. eBay's apps
demonstrate the use of different schemes by platform.
eBay://launch?itm=360703170135 is the URI that deep links into eBay’s
iOS app while eBay://item/view?id=360703170135 links into eBay’s
Android app
Basically the URL matching starts at the OS level.
iOS will use the settings in your apps plist file for a whole bunch of other things outside the app. One of them being the deep linking.
You declare your URL scheme in the plist, and whenever the OS encounters a URL matching this scheme (usually when user taps a button or link), it will open your app and pass the URL information on. It's then your responsibility to determine what to do with this information.
Does it jump into a profile page? A particular product? That's all left up to you.
I'm looking at some ad SDKs and it's difficult for me to find a way to present them without leaving the app. I've tried a handful of them but lets say AdMob for purpose of answering this question.
Is there a way to present AdMob ads in an in-app browser once they are clicked? Or would I have to use a different SDK if I want to achieve that.
If the answer is the latter, what well known Ad SDKs would let me do that?
Opening the target page in Safari and not in an in-app browser is on purpose: Safari allows to better track the users. The reason is related to the cookie handling: Safari stores cookies globally while the UIWebView based in app-browsers have a cookie store restricted to a single app. Therefore with in-app browsers, you cannot track users across apps.
However, there is a solution to mitigate the problem provided you have a certain control about the ads (and aren't simply taking the from a network).
An ad can consist of more than just an image with a target link. It can contain interactive elements. You can take advantage of it by creating an ad that opens an overlay when tapped. The overlay shows a web page within your app. The user can then either close it or tap a link that takes her to a further web page shown in Safari.
The standard API to implement an overlay supported by most ad SDKs is MRAID. Google Mobile Ads SDK (formerly known as AdMob SDK) supports it. The Google SDK additionally supports the AdMob SDK.
Good examples for such ads can be found on a Google support page. Specifically check out "Sample Code for an expandable ad (MRAID)" and "Target window: in-app overlay window".
I am developing an application that does exactly 2 things.
1) Opens a UIWebView
2) Uses push notification
I am opening a UIWebView where i load an external URL , and there the user can subscribe to various kinds of events. After he subscribes he can get push notifications about them.
I am asking because some people told me that their apps got rejected when they were just loading an external URL , because apple said it could better be a web page and not an iOS app.
But in my case where i use push notifications? Does it count differently?
The reason why WebView only apps are beeng rejected is because they dont use any of the features that the framework is offering. I got in an application that had only one view for log in, and after log in, the response was URL from server that I was showing in WebView.
You will never know unless you try, but I think it will get in.
I have successfully submitted 3 apps which are all WebViews but with Push Notification functionality. As long as you have Push Notifications in your app you will meet the guidelines of having framework dependant features in your app rather than just being a simple WebView in a mobile app.
"Your app did not include iOS features. App Store apps should use native iOS buttons and include iOS features other than just web views, push notifications, or sharing."
source: Apple rejecting Ionic apps, date: Jan, 2019
“Your app provides a limited user experience as it is not sufficiently different from a mobile browsing experience. Specifically, we notice that most of the app content links out to Safari. As such, the experience it provides is similar to the general experience of using Safari. Including iOS features such as push notifications, Core Location, and sharing do not provide a robust enough experience to be appropriate for the App Store. … the App Store does not accept or distribute web apps.”
source: App Store Rejection 4.2 - Design: Minimum Functionality, date: Dec 2020, But seems it was resolved.
Conclusion: YMMV = Your Mileage May Vary.
I have an existing iOS app on the App Store that includes Game Center achievements. Since it also has a working Facebook Connect implementation, I'd like to leverage the social channels available through the new Achievements Graph APIs with my apps.
I have created the corresponding achievement pages ready to be registered with Facebook as achievements for my app. From what I have read, since the app auth token has to be used to submit achievements and scores, I'm doing all of this on my server using some PHP scripts so I don't have to ship my secret key with my app binaries. I'm planning to have my iOS app call a script on my server when submitting achievements or scores.
I am using the same FB app that I use for the native iOS app. Obviously I want it to start generating stories and timeline events when the user unlocks achievements or reaches a new high score.
However I am running into a big stumbling block when trying to register the achievements for the FB app. I get the following error with the script that does the registration :
OAuthException: (#15) This method is not supported for native apps
I seem to be doing everything right, sending a POST to the /<appid>/achievements API with the URL for the achievements, etc.
In an effort to work around limitations on these API by Facebook, I have also enabled the existing mobile app to also be a "Website" and "App on Facebook" in the developer settings. To no avail.
So my question is... am I missing something to enable achievements that could be submitted from an iOS app through an intermediary server? I don't mind setting up canvas pages and so on if necessary, but I'd rather not have the users re-authenticate as a wholly separate app just so they can post achievements and scores to their Facebook stream.
What I'm trying to achieve is at most ask the user for additional permissions on the existing app on their devices, if necessary. It should be possible to invoke a script on my server that will push the achievements to Facebook when needed - but how ?
Is the only way to do this to use a separate FB app that is not set as a native mobile app at all, or can it be a combination native/Web app?
It means you've probably configured your application on Facebook's side as 'Native/Desktop' instead of 'web'.
In this configuration your app secret is untrusted because it's assumed you've shipped it with the client code - there's no reason your IOS app won't work in 'web' mode, so use that instead
(I'm assuming you haven't actually shipped your app secret in client code - if you have, it's a huge security problem unless your app is set to 'Native/Desktop')