I'm making WatchKit app and really really need help...
My Project Flow likes this
There are company Lists in DB
Each Companies get there own URL
Each Web sites have same design, but save different Cookies
ex) company A's URL --> save cookies like "company_name" , "A"
company B's URL --> save cookies like "company_name" , "B"
After Save Cookies, WebSite redirects to AppStore
Download App and start App.
When App is Started, App Check Cookies
According to Cookies, App change App's Splash Label
For Step 6 and 7, I have to check cookies...
Is it Possible?? and then, How?
Short answer: no, it's not possible.
Each app manages it's own cookies and you can't access cookies set by other apps unless they indirectly allow it.
Mobile Safari, the default iOS browser doesn't provide any way of reading the cookies to other apps, nor should it, for privacy and security purposes.
See similar question here Can an iPhone xcode application read cookies previously stored by Safari Mobile?
Related
My app was recently rejected for App Store release with the following reason:
We noticed your app accesses web content you own where you collect cookies. Cookies may be used to track users, but you do not use App Tracking Transparency to request the user's permission before collecting data used to track.
The last part is correct: I do not apply App Tracking Transparency.
The first part is surprising:
I do not explicitly access cookies by HTTPCookieStorage
I show a terms-of-use webpage which is included in the app. It does not access any cookies. It has links to external sites that do, but I only navigate to these by switching to safari (using UIApplication.shared.open(...))
So: How do I figure out how/when cookies are accessed by my app, which makes apple require App Tracking Transparency?
I ended up asking Apple about the haps, and the reply stated the following:
we still find that your app indicates the collection of cookies on launch
After a bit back-and-forth, I removed some text in the bundled terms-of-use webpage - something copy-pasted from the website supporting the app, that indeed indicated collection of cookies... Completely irrelevant for the app.
That did the trick, and the app is approved.
Would like to know if expected behavior on deep linking using branch.io so when clicked on should check for app availability and prompt customer on iOS device to
Prompts to download app in App Store if not installed
Open in iOS app seamlessly if installed
If customer declines app download it will open in iOS mobile browser
My concern is this deep link behavior on a desktop experience. When a user clicks the same url I am being told this will take them to the iTunes app store resulting in a poor experience. Is this a correct statement? Is there any way to provide a better experience to the end user.
Thanks in advance!
I am being told if the same url is opened in Windows10 it will take me to the App
For example
1. Users opens email with deeplink url
2. what is expected behavior on mobile device with app installed that deep link
For iOS redirects, you'll have to set yourself up for Universal Linking per the documentation here:
https://dev.branch.io/getting-started/universal-app-links/guide/ios/
This is very important for redirect behavior on iOS 9 and later. Please note that not all 3rd party apps and browsers support Universal Linking functionality yet, so you should test on iOS from iMessage or Notes initially.
As for Desktop, you can set your Desktop redirect on the Link settings page - this will not take users to the App store/Play store on Desktop, but to the page you set. You can use the Branch hosted text-me-the-app page if you want to have this as your default for Branch redirects, or your site homepage, or any other page of your choosing. You can add Deeplink data that will be used for all redirects by adding key/value pairs in the SDK or manually when creating a marketing link from the Branch Dashboard. You can also set a $deeplink_path value that will be honored for a specific link, and you can further set a $desktop_url that will override defaults if you want a different redirect for a specific link.
There are many options and ways for you to configure how your redirects work - all of this is up to how you set your Link Settings on the Dashboard, and if you choose to override these defaults for any particular link. For example, you might have default redirects to the App store set for iOS and a desktop URL set to your main webpage on Link Settings. In this case, a link created without modifying these values will take the user to the App store on iOS (or the App if installed), and to the desktop URL specified in Link settings if clicked from Desktop. If, however, you want to override and set $desktop_url as something else for a given link, say, to a specific page on your webpage using the $desktop_url key, on iOS the redirects will be the same but on desktop you will be taken to the set $desktop_url. For any of these scenarios you can specify Deeplink Data to be passed through.
I have an app that gets opened from another app via a URL scheme. The URL contains signup tokens. As any app can register the same URL scheme as my app, I am concerned a "fake" app can do a man-in-the-middle attack and capture the signup tokens.
My idea is to check that the URL scheme does not open another app when my app is first opened.
From a security perspective, if the URL scheme opens my app the first time, will it always open my app in the future?
How about using iOS 9 universal links?
Unlike custom URL schemes, universal links can’t be claimed by other apps, because they use standard HTTP or HTTPS links to your website.
https://developer.apple.com/library/prerelease/ios/documentation/General/Conceptual/AppSearch/UniversalLinks.html
This way the "dispatch table" is on your server, so no other app can hijack the signup URL. (URL dispatch is based on AppIDs)
It's a valid (and usually ignored) attack vector. It isn't strictly a man-in-the-middle attack as it won't forward the URL on to your app (it can't). It's almost worse as the attacking app would only really be able to crash and it would look like your app had...
Another app could be installed any time your app is in the background. Technically it's possible that an update is released and installed for an existing app while your app is running (it's hard to know if that happens). So, it isn't safe to only test when your app is first opened.
I am looking to submit an app for review by the Apple team - the app is geared towards schoolchildren upto the ages of 17 - when I attempt to submit I see an option called Unrestricted Web Access Yes or No.
If I select Yes it states my app age rating is 17+, if I select no this changes to 4+.
My app doesn't have any ability to load a browser within the app so I would presume I can simply set this to No?
I obviously don't want to get the app rejected especially as it seems to take Apple forever to review it
Unrestricted Web Access means user can browse any url like a web browser. If you are simply using a UIWebView to display your web contents loading through a url that will be called "Restricted Web Access" I think.
You can simply set "Unrestricted Web Access" to "No"
If you provide an internal web browser or UIWebView which allows to the user access to any URL you have to select YES or your app will be Metadata Rejected.
When you are submitting your app to Apple app store, there is a section named "Rating" where you should rate your content based on the chart and identify how frequently the content appears.
There is one option called "Unrestricted web access" which there are no further details available about this on the Internet nor iTunes Connect Developer Guide. All you can find everywhere is:
Select Yes if your app allows users to navigate and view web pages, such as with an embedded browser.
What does this mean? Does this mean your app can open links in embedded or Safari browser? Or does this mean your app features a browser where users can enter URLs and navigate through the web unrestricted? Because saying yes to this question will make your app 17+!
If this means opening links from your app (Safari or embedded), how come other apps that have embedded browser capability have 4+ rating (like Twitter and Facebook)? As it can be seen in screenshots, there is no way to select this one and not be rated 17+
Update: My app was approved with embedded WebView (TOWebViewController) with the answer "No" (4+). As the answer mentions, any way you let users navigate through the internet such as dynamic address bar that means it should be "Yes" (17+) because it is not possible to do Parental Control on your WebView.
Update 2: Since the release of iOS 9, Apple has introduced SFSafariViewController which is a way of opening any URLs on the internet. This feature also has an address bar but read-only. So users can't surf the Web without parental control. It also inherits content blocking from Safari (ads, explicit content, etc.). I am highly positive by using SFSafariViewController in iOS 9 or above you still can choose 4+ as the device with parental control can't open any URLs anyway. (Let me know if I am wrong)
Update 3: Twitter now is 17+ based on the followings:
You must be at least 17 years old to download this application.
Infrequent/Mild Profanity or Crude Humor
Frequent/Intense Mature/Suggestive Themes
Infrequent/Mild Sexual Content and Nudity
Update 4: It is possible to use Twitter content inside your app without inheriting its rating (17+). My app is displaying Tweets, but since the users are verified and trusted public figures I could go down to 12+:
Infrequent/Mild Sexual Content and Nudity
Infrequent/Mild Profanity or Crude Humour
Infrequent/Mild Mature/Suggestive Themes
It means that a user of the app can access any URL. The issue is parental controls. If the parent has restricted web access an app that allows unlimited access, that is access to any site the user chooses then the parental controls are subverted.
Once Apple provided parental controls that caused a ripple effect on the capabilities of apps and also required Apple to review all apps for parental control violations. It also means that alternate app stores could not be allowed, they could contain apps that did not properly honor parental controls. Hence:"The Walled Garden."
I think if you use default WebView control it is ok and you don't need to set Unrestricted web access to YES. My app has defaut WebView control with dynamic address bar and if i turn ON restrictions (limited websites access) embedded default WebView control does not display restricted content. It behaves the same as Safari app. So i would say you only need to set this to YES if your app has third party WebView control which can not be controlled by Apple.
TO CORRECT MY OWN ANSWER: sorry, but not true. If your app uses any kind of WebView (default or third party) with option to access any website you have to set Unrestricted Web Access to Yes otherwise your app will be Metadata Rejected. It just happend with my apps!
If you provide an internal web browser or UIWebView which allows to the user access to any URL you have to select YES or your app will be Metadata Rejected.
My app just got rejected because it has a link to the corresponding article on wikipedia. My guess is that because wikipedia allows you to search for other articles on wikipedia then it is considered "Unrestricted Web Access" and resulting 17+ app rating.
Kind of extreme in my opinion.
Hope, You have got your answer.
Let me ADD some more specific question, I think it will help.
QUESTIONS :
Does a link that opens in an external browser (like iOS Safari) constitute "Unrestricted Web Access?"
Does an embedded browser in an app without a URL bar constitute "Unrestricted Web Access?"
ANSWER :
If your app uses the embedded browser (which does not display a URL bar) and the link does not reference objectionable content, then you should not need to label it "Unrestricted Web Access."
If your app calls up an external web browser (like iOS Safari) and the link does not reference objectionable content, then you should not need to label it "Unrestricted Web Access."
Apple has not specifically addressed these questions and leaves it to the review process to determine whether the rating is correct. Through my own investigation, I have observed the above.
I use the Ionic/Cordova In-App browser plugin and no issues here with that. i.e. user cannot change the URL of it. So the answer here is NO
https://ionicframework.com/docs/native/in-app-browser