Great question @daniel.c.rauschk96lu - I’m working to get a list of what’s used and how it’s being used at the moment, hoping to have an update for you later today on this.
Any news on this, @domhnallohanlon? I’m waiting to publish an app update and stalled here as others are.
2 Likes
We need an update on this. We also need to understand for how long this has been going on and what data you have collected for each of the App IDs each of us has in his projects list. This needs to be sent to us privately and securely.
3 Likes
Hey @tatiang,
The follow up I got was that we’re not collecting any PII (personally identifiable information) about your users from apps that you build with Thunkable.
In this specific case we use Bugsnag to collect anonymous crash data about the make, model and OS of devices. It is not used for tracking so there are no issues here in relation to data protection regulations.
Just for a little more context here, Thunkable is totally committed to protecting the privacy and privacy rights of all our users (and, in so far as is possible, those of your users too) We have invested considerable time (and money!) at a senior management level working with our own attorneys and with a specialist team of data protection lawyers to ensure that we are in compliance with the latest data protection legislation globally. The culmination of this was the updated privacy policy which we released last November. Since this is an emerging and evolving field of the law we will continue working into the future to make sure that we remain in compliance with any new policies or regulations that are released in the future too.
Here are the steps you will need to follow in order to publish you app:
1. App Privacy
In App Store Connect, click on “App Privacy” on the left hand side of the screen and click on the blue “Get Started” button.
2. Data Collection
Even if you don’t have any sign in, location, payment or advertising services in your app you will need to check Yes in this modal:
3. Crash Data
Bugsnag is used to collect anonymous crash data so scroll down through all the options check the “Crash Data” option.
Again, if you are logging any other user data you will need to check the appropriate boxes there too.
4. Set Up Crash Data
Back in App Store Connect you will now need to add the reasons for collecting crash data. Click on “Set Up Crash Data” to begin
5. Data Use
The data are used for App Functionality purposes - specifically to minimize crashes and improve performance.
6. User Identity
Since the data collected in anonymous, you can select “No” in this screen:
7. Tracking
Again, none of the data are personally identifiable or used for advertising purposes so you can select “No” again on this screen:
8. Done
Back in App Store Connect you will see a preview of what this will look like in your app listing.
Furter Reading:
You can see a full explanation of all the above terms on Apple’s Privacy Website here:
cc: @funhall @daniel.c.rauschk96lu @bedgepsnq @Michael_Rogulla @Carlos_Escobar @zimat.bed9ut @kizzy @fredyfernando @knownkeep @jared @Richard_Fellows @emregoker @dlmetzgerbcch
5 Likes
Thank You!
Glad to hear it and thank you for the screenshots explaining the process.
@domhnallohanlon You need to allow for opting out of all tracking. There’s no reason to force this into every build.
And this is new, because I have previously shipped/active apps that Apple did not report as having this tracking. Only my recent releases reported it.
It’s not hard to program if customer doesn’t want tracking then don’t include this library and this global function call.
No problem at all!
Just to be super clear here @knownkeep we are not doing any “tracking”, which as defined by Apple is collecting PII, and in particular they’re concerned about this data being used by advertisers.
“Tracking” refers to linking data collected from your app about a particular end-user or device, such as a user ID, device ID, or profile, with Third-Party Data for targeted advertising or advertising measurement purposes, or sharing data collected from your app about a particular end-user or device with a data broker.
Apple have only recently started flagging this in the past week or so, it’s not particularly new to Thunkable, but I don’t have the release date for this to hand at the moment.
Again, the telemetry that we’re getting is not customer tracking, it’s anonymised and generic crash reports. I can’t speak to the difficulty, or otherwise, of making changes to our iOS build system, but I will certainly pass along your concerns.
1 Like
@domhnallohanlon Since we’re stuck on semantics of words used, then “you need to allow for opting out of all collecting”. Look, I don’t care what Apple approves or doesn’t approve related to this… I don’t want our apps collect/tracking/using any information that isn’t necessary. And bug logs are not necessary for all apps. You could even create a support policy that says if you don’t allow BugSnag/X, then we can’t support your apps. I’d be OK with that. I need to be able to disable all collecting/tracking so I can be truthful in our privacy policy (we have separate policies for apps than the one you saw on our main site).
3 Likes
Just wondering what this assertion is based on? Why is anonymous crash reporting unnecessary?
Not to be flippant or anything, but could you update your privacy policy so that it reflects the changes rolled out by Apple in the past week?
I mean, extending this logic, if we make future updates to comply with future privacy legislation, are you going to ask us to roll those back so that you can be truthful in your existing privacy policy?
Policies, by their very nature, are meant to evolve. They are written with the best intentions and information at a given time and, with usage and technological progression, need to be periodically reviewed. A really good example of this would be a country’s constitution. The people who write them do so with the best intentions in the world but every now and then even the greatest ones need amendments.
Can I respectfully propose that you add something like the following to your privacy policy:
This app uses Bugsnag for anonymous crash reporting. It gathers information about the make, model, and operating system of a device in the event of a crash occurring. No personally identifiable information (PII) is collected, stored, or transmitted during crash reports.
Since you brought up semantics, I’m going to have to insist that you use the Oxford comma as per my draft above 
EDIT:
Sorry @knownkeep, I just saw the message you sent in via chat now, so I understand your situation a little better than when I originally posted. With that being said though, I still think you should at least consider updating your privacy policy. Discuss it with your team and let me know via the chat what comes out of that conversation.
3 Likes
Because I say it is. I have been doing mainframe and Windows programming for 30 years. I’ve run my own “small” multi-million dollar software company for over 20 years. I’ve been supporting customers a long time.
Yes, logs are helpful. We generate logs for our Windows apps, but we do NOT automatically submit them. The customer is allowed to do that. In this case, I’m your customer, and I do not want to submit logs. Auto-submitting logs turns our apps into bug submission apps to make Thunkable better. I’m happy to report issues, but on certain apps, namely our children’s apps, I do not want any tracking. And I pretty much do not want tracking/collecting on any apps.
You’re still VERY confused as to who this request (demand) is for. This is NOT to comply to Apple. This is NOT to comply to GDPR. This is to comply with ME, my requirements. I (my company) does not support anonymous data collecting. Period. Before Apple’s app store, before GDPR, before all of this, we have always been against unauthorized data collection.
Even before it was frowned upon, we have never sold our customer database. We never shared customer data with other companies. And now that Google is so out of control, we’ve stopped using Google Analytics.
For non-children’s apps I would be open to it, but no, I do not want to do it. I’d prefer to be a company who has a short, simple privacy policy which states we do not track or collect anything.
We don’t even have a registration option for our children’s apps.
And I’m a fan of the Oxford comma. No argument there. 
I appreciate your engagement on this topic.
4 Likes
I don’t mean to be rude, but why are you using Thunkable X then?
Do you think Thunkable is only for broke, non-programmers to make apps?
We use it because it’s visual and fast to prototype (and build) apps. And apps that work on both iOS and Android.
And if you’re wondering why we don’t hire an iOS and Android developer, it’s because that’s expensive for our minor needs. We don’t do nearly enough mobile app development to justify full time iOS and Android developers. And you focused on the multi-million part of my answer, and not the “small”. We can’t pay $200K-400K plus benefits for developers we hardly use. We are primarily a Windows software company. We’ve been outsourcing the building of some of our apps for years, but that’s been very frustrating, because the great developers charge too much, and the bad developers are just so sloppy with interface design. The “no-code” platforms finally becoming viable were a godsend. It should be noted that if you do program in most any language, you can rapidly develop apps with Thunkable and the likes.
Oh, and you may wonder, why don’t you just learn iOS or Android programming yourself. I’ve been able to pick up iOS OK, but struggle with Android. There’s just too much to learn to manually code for both platforms. Even simple apps. It would take too much extra effort to get good at these other development environments. Thunkable and the likes solve the problem quite well.
And I would have never mentioned “multi-million” in a reply, but I was asked to clarify where I’m coming from, and I thought my background was important to mention.
7 Likes
It seems with this forced introduction of Bugsnag, Thunkable is sending a clear message here. Accept it or Leave the platform
I’m forced to take the second option for no reason but Thunkable decided to force it on all users.
I don’t care about store guidelines. Actually, the apps I create are specific to the client and I provide it as Android build without publishing to the store but I’m not willing to introduce any third party app inside my app which I cannot control.
Thank you Thunkable.
6 Likes
I have to agree with @knownkeep & @muneer on this one, passing this off as a change in apple’s policy and marking as solved seems a little premature. In my eyes this is far from solved!
I would be happy to include this in my apps if it was offered as a design element/block so i could allow my customers to opt in or out of the service?
Until there is a suitable resolution the bugsnag service should be removed imediately.
5 Likes
We will work on a reasonable fix soon and potentially remove Bugsnag from our master template. I will give an update in the coming week, hopefully before Tuesday PST.
Best,
Wei
5 Likes
Many thanks @wei
That announcement made my day. Waiting to see it in action.
4 Likes
Hi everyone,
BugSnag has been removed from the build process on our end. If you download or publish a new iOS or Android app from this point forward, your app will not contain BugSnag.
Thanks,
Jane
6 Likes
Hooray 
1 Like
Thanks guys. Just to reiterate, I would be open to adding this if it could be done through an opt-in process for end users.
2 Likes