Am trying to figure out the Do's and Don'ts of implementing push IOS\Android native app for kids regarding GDPR (US is not in our scope).
Did not find any relevant, cohesive and doublechecked info.
Any clues?
Related
I complete my app and publish it to google play
but when published to the app store. I facing this message from apple.
App rejected on 4.2 Design: Minimum Functionality
and I afraid apple rejected my app because it made by Flutter, not Xcode.
note: My app includes GPS, notification, Facebook login, Facebook like, send message
It's a good idea to read the App Store Review Guidelines before send an App to the App Store, but as a developers sometimes we forgot it. What I can suggest you, because once I have a similar rejected case but in other field, is to check each term in the section 4.2 Minimum Functionality in the guidelines. Another thing is that you can send an email, requesting more information about the rejection, but that you have made your app with Flutter, absolutely is not the problem.
As Luis Miguel Mantilla mentioned, you could start by checking out the guidelines — App Store Review Guidelines: 4.2 Minimum Functionality — pointed out be the person who rejected you.
Rejection of an app is extremely common with Apple, because the are very strict, bureaucratic and inflexible, in an attempt of trying to maintain a high quality app store. Even with big apps, it's very common for people to face many rejections before managing to get a build in.
Their strictness also causes their reviewers to either be imobile or seem dumb. For example, in a first app I tried to build, I had implemented a basic login initial screen; and, because they have guidelines for the reviewers about the login, the reviewer simply didn't do anything and rejected my app — I think I had to necessarily provide test users —, even though he could have simple created a dummy test user by himself — I had informed so in the build description.
Another way of solving your rejection problem is by contacting your reviewer directly. When your build is rejected, you will receive an email like this:
Dear <your_name>,
Your app, <app_name_and_build>, has been reviewed, but cannot be made
available for TestFlight beta testing.
For details, or to contact App Store Review, visit Resolution
Center in App Store Connect.
Best regards, App Store Review
By clicking on the Resolution Center link, you will be able to talk to the person and poke out what's really going on, instead of having to suffer from anxiety by endlessly speculating over it.
Lastly, this article was somewhat useful when I was first rejected.
Our app was finally released by Apple after several attemps. Here is what we changed to get the app accepted:
We added an exact description of the app functionality in English.
We wrote a text addressing the review team to explain how the users can benefit from the app and what is the intention of the company publishing the app.
We made a screenshot showing the Apple maps integration of the app.
I hope this can help you to get your app accepted.
I want to use Firebase Cloud Messaging in a healthcare application. I want to know is FCM HIPAA Compliant and does it provide BAA?
We’ve just completed the HIPAA audit with a 3rd party for a Firestore Chat sample app (iOS and Android) that’s using End-to-End Encryption. If you’re implementing a healthcare Chat app, keep reading. Otherwise, this isn’t relevant.
The challenge: if you know how E2EE works, you realize that it alone should protect your patients’ data from Firebase/Firestore: apparently, lawyers don’t agree with that. So we had to implement an artificial data redaction that deletes chat messages from Firestore as soon as the messages are delivered. This enables your app to qualify for HIPAA’s Conduit exception, because it only acts as a message delivery system, it doesn’t store permanent health data. This way, your chat solution is exempt of HIPAA.
We’ve compiled the solution into a How-to blog post: https://VirgilSecurity.com/hipaa-firebase - with pointers to reusable sample apps.
Whitepaper that contains our HIPAA audit & 3rd-party data privacy expert’s notes: https://VirgilSecurity.com/firebase-whitepaper
According to the co-founder, as of now Firebase is not HIPAA compliant.
You can take a look at the updates here: https://groups.google.com/forum/#!topic/firebase-talk/sg-WCHVXs5k
I am about to submit an app to the Apple AppStore built in Swift that uses Crashlytics to capture crash information. As users of Crashlytics know, some information about usage, duration, crashes, etc. is captured and stored on the Crashlytics servers. My application does not ask for, store or attempt to capture any user data.
My question is about the privacy policy for my application. Since I don't capture any user data, I want to state that in my privacy policy but I'm not sure that's factual since I am using Crashlytics. Any feedback on people that have used Crashlytics in their app and have an actual privacy policy?
Thanks
--Vinny
Quick answer: yes, you need that privacy policy. There are ways to get it done fast, too.
Longer answer:
Third parties (here Crashlytics)
When dealing with a third party service like this, often a quick look into their legal documents will help (for Crashlytics in this case as described in your question).
(...) At all times during the term of this Agreement, Developer shall
maintain a privacy policy (a) that is readily accessible to users from
its website or within its online service (as applicable), (b) that
fully and accurately discloses to its users what information is
collected about its users and (c) that states that such information is
disclosed to and processed by third party providers like Crashlytics
in the manner contemplated by the Services, including, without
limitation, disclosure of the use of technology to track users’
activity and otherwise collect information from users. (...)
And
Developer shall at all times comply with all applicable laws, rules
and regulations relating to data collection, privacy and security,
including, without limitation, the Children’s Online Privacy
Protection Act (“COPPA”). Crashlytics may, at its sole discretion from
time to time during the Term of this Agreement, audit Developer Data
to verify compliance.
Crashlytics is actually being unusually vocal about this topic.
The App Store
At the time of writing (and since iOS8) Apple requires privacy policies for 5 categories:
Kids Category, HomeKit, HealthKit, Apple Pay, and Keyboard Extentions. Also they require privacy policies for user registrations (more). I can't tell if any of the above for your app is true. Apple still says in their App Store Review Guidelines that you need to be compliant with all applicable laws. This brings us to the third and most important reason.
Privacy related regulations
All of the above is just there because of global privacy regulations, these companies would most likely not care otherwise. As soon as you work with User data you are mostly under an obligation to disclose these facts. It's personal data like names, addresses or the tracking of user behaviour. It's been written at length why analytics services need privacy policies. All of it is more important as soon as you share data and use third party services for it. Mostly the disclosure or some kind of consent is the condition for it's compliant usage.
If you are interested in reading more about the matter in the context of mobile apps I'd suggest any of these documents:
ICO UK
Ireland
USA/California
Canada
Australia
Hope this helps.
(For proper disclosure: I do some work for iubenda, a tool that helps creating privacy policies for apps and websites)
Vinny, I think it's not mandatory (I've seen apps using Crashlytics wihtout a privacy policy), but it's recommended to have transparency in the communications with your users.
Crashlytics already has a privacy policy so you can just use that policy and add a statement informing that you are not collecting any sensitive information from the user, such as email or phone number.
We have a very basic application (iOS/Android) done in Appcelerator that will receive a single update every week. This update will be sent to all the users subscribed to the push notifications service.
By this moment, we have around 35k installs but 7,000 active users on this application on last month. We've been evaluating two services for all the push notifications:
StackMob
Parse
Appcelerator Cloud services is fine, but we're not willing to pay that much. Parse and StackMob prices are lower than Appcelerator Cloud services and by our analysis, we could even use the free service on both services (StackMob = 60k push notifications + 60k api calls, and Parse 1M api calls + 1M pushes).
If we're going to use Parse, we'll need to buy the Android and iOS module from the Marketplace ($30/year each). Which is fine. On the counterpart, I think we could use the REST API on StackMob for subscribing to the push service.
Questions:
What are your thoughts on both services? Which one do you prefer and why?
Have you used StackMob REST API for subscribing to push notifications?
How do you retrieve Android's token?
Is there any (cost effective) alternative to these services? I also reviewed PubNub, which seems to be great but costs are higher than StackMob and Parse.
Thanks in advance.
Update
I asked the same question on Appcelerator forums. After a while, users came back with several answers and users using Parse.com for this.
I ended implementing Parse.com, which was really simple by using the Android and iOS plugins that are on the Appcelerator Market.
I wanted to chime in and point you to some StackMob references around Appcelerator.
Aaron Saunders has several projects on github showing how to use StackMob with Appcelerator.
https://github.com/aaronksaunders
He also wrote a series of blog posts about it.
http://developer.appcelerator.com/blog/2011/11/titanium-appcelerator-quickie-stackmob-api-module-part-one.html
Our REST API reference is available at https://developer.stackmob.com/tutorials/dashboard/REST-API-Reference
One of the big differentiators between StackMob and others is our custom code option. You can write your own logic in Java, Scala or Clojure and host it on StackMob. The custom code can interact with your user data and other 3rd party APIs.
https://developer.stackmob.com/tutorials/custom%20code
I haven't used those services myself, so I cant comment. However, Another alternative we use (and have been pretty happy with) is Urban Airship. It's relatively cost effective, supports Android, iOS and BB and it has server side libraries for a bunch different languages. There is also a neat blog post outlining how to easily do device registration (at least for iOS) via simple web requests in Appcelerator.
The blog post on its Appcelerator integration is here.
I've looked all over and found nothing about this topic - For people making mobile app games and want to sell levels or potions or whatnot from within the app, is this supported on Flex mobile apps? Are there plans to introduce it? I've found info about advertisement implementation... is this a possible next step? Do you have to use something like PayPal instead of Android Market?
Sorry if this has been asked, but I haven't found anything yet.
Thanks!
I know Adobe said at GDC Conference they are in the process of analyzing requirements to make in-app purchases available via Flash Player API. It's almost a year so far since that announcement but there has not been any further news. The work around/the way most client-server implement these business rule is on the server-side where they implement an entitlements model.
Yes, there are several native extensions that implement this functionality.
I have been using the ones from Milkman Games with good results, and the support is fantastic. No financial association, just a very satisfied user.
There is also a free iOS Storekit ANE as well, although in my experience with it there are still some bugs, notably with blank receipt values for restored transactions: http://code.google.com/p/in-app-purchase-air-ios/
Note: implementing your own entitlements is ill-advised for various reasons:
Apple doesn't allow using anything other than their own in-app
purchase API on iOS.
The various store implementations (well, Apple's
and Amazon's at least, Google Play is another story) handle all of
the details of international purchases and localized pricing for
you.
The store implementations handle payments, subscriptions, durable purchases, and a host
of other details that you will spend a lot of time getting right on your own.