I am building some services that will scrape data from a number of websites and be stored into a database. I am then using services to call this data into an iOS app and display it in an organized manner that will be useful to users. Will my app be rejected due to this policy?
12.3
Apps that are simply web clippings, content aggregators, or a
collection of links, may be rejected
I am not using any child browser, etc. When a user views the data within the app they may click a link to go to the specific webpage in Safari separately, but there is no "Buy" button, etc.
As long as you're adding some value to the content I don't think you have a problem. Look at Flipbook; it basically rehashes people's web data, but it a useful way. Aggregation itself isn't bad, it's people who don't put an effort to curate or correlate the data is where I believe Apple has a problem.
tl;dr: It depends on how you implement your app.
Related
I've a question regarding to releasing my iOS application.
Is there anything I should think about when releasing? Should I let ALL countries be able to download the application, if not why?
I mean, I've no idea about all the countries rules regarding to everything. On my IOS app I've a map which you can start and it will track your moves till you press a stop button. And I also have links to "third-party's (To shops, blogs, instagram accounts etc)"
Should I allow my app in all countries? If not, which one should I remove?
This is really an offtopic question, countries you want to distribute your app to depend on your business logic. Unless you have some questionable content (for example China has some strict rules regarding content and maps) or store user data without GDPR (European Union), you're almost certainly good to go.
i am in the process of making my app with firebase i am pretty much done with that except Firebase App Indexing. I am very exited with this feature because it could help me to increase my app get more traffic from the web but the problem is i really can't able to see how to implement this. According to Firebase Docs i just need to register my app with this pice of code
[[FIRAppIndexing sharedInstance] registerApp:your Apple ID from iTunes Connect];
I have done that but what should i do after that?
1.My app is firebase app that means i don't have any website to host my content except firebase realtime database. Does my content is available for crawlers? if not how can i make available to them?
2.If i can able to show my content in the google search results i don't wanna show all the content and i wanna show just some of my content for example i have a social app for sharing General Knowledge questions, i wanna show just the question like "What is the highest mountain" in the search results and if the user want to see the answer it should take them to my app how can i do that?
3.As per docs i came to know that i need to create univiersal links for my app content to direct users from google search but how shold i do that ? Lets say should i crate universal links when the user create question?? if so how can i do that ??
Thank you very much for the help.
This is not currently possible on iOS using Firebase App Indexing. The situation is slightly different on Android, but that is not applicable to your question.
On iOS, Firebase App Indexing is simply highlighting pages on your website in Google search results that have corresponding content inside your app. This is achieved by piggybacking on Apple's Universal Links standard, and there is no proactive 'crawling' going on inside your app. This means unless you have a corresponding web page for your app with 1:1 content parity, you can't really benefit from Firebase App Indexing on iOS as it comes out-of-the-box.
The best workaround is to generate little 'placeholder pages' for every piece of content in your app, which the sole purpose of opening your app (if it is installed) or redirecting to the App Store (if it is not installed). Ideally you'll need some sort of deferred deep linking system so that users still see the correct content after downloading. Fun fact: this is essentially how HotelTonight operates their entire business model. Unfortunately Firebase's implementation is not mature enough to support this full flow, and Google hasn't quite figured out how to rank app-only content properly yet in search results so you will probably need to pro-actively submit your placeholder pages to them.
Shameless plug: at Branch, we provide all of the above as a free service. You can read more about it here and take a look at the set up docs here.
Is it possible to read the contents of another application installed on an iPhone? What about from an extension or keyboard?
I'm trying to come up with something that 'checks' other apps to see if they have any deep links (like Twitter's Twitter://timeline that takes users straight to the timeline in the Twitter app).
Is there any smart way to check a given app for deep links?
Is it even possible to peek at another app's contents from within my app? I suspect no.
If no, what about making a keyboard or extension of some sort that I can access from an app like Twitter and see its contents, such as a URL deep link?
You don't have much options, you may use -canOpenURL:, but, since iOS9, must include special credentails listing all the custom schemes you want to check.
You can't read other app's contents on a non-rooted device unless this app is sharing a keychain (so it can exchange data via the shared keychain). The same thing goes with extensions.
iOS has some high bars on security, so, don't expect much or even, anything.
Something you may want is IntentKit. Also there are ideas around the web about standard url query format like MobileDeepLinking.
We're trying to implement deferred deep linking in one of our iOS applications to encourage users to invite their friends to use the app, and reward users based on how many installs occur from their referral link. Basically similar to TapStream's product.
Consider this example:
So, UserA shares their link, “ourappURL.com/refer?id=userA”, on any
network they want. UserB clicks that link, which will take them to
Safari and then bounce them to the App Store page where UserB
downloads the app.
When UserB opens the app, the app checks which referral ID they came
in on (if any). In this example, the referral ID would be “userA” as
that’s the ID that was in the referral link. The app then sends this to
our servers and we award UserA with a referral credit.
I'm trying to break this issue down into its core parts. I believe the first part is getting the web page for the user's referral link to save the referral ID to the device somewhere that the app can access it. But I'm not sure this is possible because of the sandboxed nature of iOS.
I know this is fundamentally possible because many ad providers offer the ability to track installations from an ad campaign (see Mobile App Tracking for example).
We have also attempted to do this ourselves and I will try to break down the different steps here.
Going back to your example, you are correct about "remembering" the device identification, and all relevant data "id=userA". You are also correct about "sandboxed nature of iOS" which I presume it means a web page is not allowed to store information outside of the browser app (Safari) and apps (your app) are not able to access information stored by other apps (Safari).
Our solution to this is to store this device to data key-value pair in an environment that is both accessible by the browser as well as by your app, i.e. your backend server.
The next challenge, which remains to be the biggest challenge, is how to uniquely identify this device from the information collectable from the browser? Javascripts in browsers, unlike native apps, don't have access to IDFAs which could be used to uniquely identify a iOS device. To overcome this, one can imagine to use a combination of common information that is available both to the browser app as well to your native app, i.e. OS type, public IP, screen size, etc. etc. Please note, a composite key from these data fields does not guarantee uniqueness (imagine two iPhone 6 visiting this web page via the same router). Therefore, your backend server (assuming you are using it to store this key-value pair), will want to have a strategy on how to handle collisions on keys i.e. the second key deletes the first key, or you allow collision to exist by having a queue of values for a single key. This really depends on how you actual plan to use this technology.
The last step is to form this composite key on your app using the exact same fields you used earlier in the browser to perform a "lookup" on your backend server to retrieve the value previously stored.
Here is a summary of the steps:
User 1 invites User 2 by sending the following link to 2: example.com?inviter=1
User 2 visit Web Page P
P constructs and sends the following key-value pair to your server S iOS|55.55.55.55|750×1334 -> inviter_id=1
User 2 goes to the app store and downloads your App A
User 2 first launches A, A contacts S with the same key (assuming the IP hasn't changed).
S finds the value inviter_id=1 by using this key passed in and, let's say, reward User 1 five points for inviting 2.
Hope this help!
Edit 04/24:
Since Derrick mentioned it in the comments, I figure I would take this chance to finish our story here.
Going back to the beginning of my answer where I mentioned we've attempted to do this ourselves. We had a working prototype based on our current system architecture (which is not in anyway optimized, or meant to be optimized, for storing and analyzing deep link data like this), we ultimately decided not to allocate any additional engineering resource into this project.
Due to the heuristic nature of this matching process, we found this project needing debugging, tuning and optimizing constantly for a diminishing ROI. More importantly, we have found other companies which are more specialized and do a much better job than ourselves.
It has been probably 6 months since we stopped using our internal system and we haven't regretted making such decision.
During this processes, we've worked with a number of vendors, Appsflyer, Adjust, TapStream and we have ultimately ended up with Branch Metrics https://branch.io.
Whether you should DIY or work with another company again depends on your specific objective. We finally decided to stay with Branch, not only because the other vendors charged anywhere from $500 to thousands of dollars per month while Branch is completely free, but also the level of the support they have provided is simply unparalleled.
We've successfully used the clipboard (NSPasteboard) to achieve this: the web page that processes the redirect to the app store does a paste to the mobile device's clipboard before letting the user download the app. Once the app is installed, it uses NSPasteboard on first launch to check for an appropriately coded string. This string can contain the text of interest or, more securely, a token used to fetch interesting data from the backend. In Objective C:
UIPasteboard *pasteboard = [UIPasteboard generalPasteboard];
NSString *pasteboardString = pasteboard.string;
The clipboard can be cleared once the app is done with it, to avoid repeating the same action.
There is a good solution here: http://blogs.innovationm.com/deferred-deep-linking-in-ios-with-universal-link/
Basic workflow:
User selects domain link on web.
Link sets referral ID to cookie.
User redirected to app store.
On app launch, load referral page in SFSafariViewController.
Referral page checks for cookie and if it exists calls a deeplink into the app with the referral ID.
My answer from HERE
Apple no longer supports Deep Links. It is now called Universal Links and works a bit differently.
Source
Now that Apple no longer supports URI schemes for deep linking, developers must implement Universal Links in order to deep link properly on iOS. If you are already using URI schemes, check out our blog on transitioning to Universal Links.
From: HERE
And HERE is another article on Universal Links and what they are.
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.