Hi, Do we have any known issue with internal builds not being tagged properly as internal on TestFlight? Is anyone else having the same issue? Our team is not being able to do internal builds anymore since the last week or so. The last build we have that was successfully tagged as internal was on Wed Jul 3 00:15:40. After that mark, we can upload the builds and they show up on TestFlight, but they are not marked as internal and they can technically be used for a public release even though they shouldn't. We thought this could be an issue with our CI workflow, as we did some changes around that time, but we tried reverting everything or building from an older commit and the problem isn't solved. We even tried building and uploading directly through Xcode, without going through our CI or any external tools, and even selecting the TestFlight Internal Only distribution method, the builds are still releasable (not internal). On the CI side, we have confirmed multiple times that our ExportOptions.plist contains the
missing package product
42,936 results found
Post
Replies
Boosts
Views
Activity
@DTS Engineer Quinn! I've always wondered why that drag failure would happen for (seemingly) some people. Thanks. I find it strange that a user is allowed to double-click the symlink to open the folder, but that same user isn't allowed to drop onto the symlink. In testing on the latest Sonoma, I'm finding that even dragging the (unmounted) notarized dmg to my Desktop is not removing quarantine, which seems a bit strange, and means there are no common circumstances where a downloaded dmg with non-allowlist symlinks will work as expected. Overall this is a pretty bad experience. I guess the best solution (besides an installer pkg) is to explicitly tell the user in the dmg background to double click to open that Components folder, and then drag and drop the file into the new Finder window, versus telling them to drag and drop onto the symlink in the dmg's window.
Thanks for the reply. Just to give context I am a full stack Swift developer and I am building a library to ensure my development devices (iPhone, Apple Watch, etc...) can find my development Swift Server (Vapor, Hummingbird, etc...) https://github.com/brightdigit/Sublimation I have successfully been able to transition from other solutions to using Bonjour to advertise the ip address of the server using NWTxtRecord. My next goal was to use SwiftNIO: https://swiftpackageindex.com/apple/swift-nio-transport-services/1.20.0/documentation/niotransportservices/niotsconnectionbootstrap as opposed to NWListener. It was using that which I ran into the previous issues mentioned (never getting a complete message). I then tried it as you see in the test code and noticed the requirement for using cancel. These messages are typically pretty small (encoded Protobuf) around 500 - 2000 bytes. For both NWListener and SwiftNIO: In no cases did the server crash, in fact the server would log correct that it did send the message.
Using NWBrowser and NWListener I'm trying to send a small package of data from the listener/server to the device. However the device never receives the actual bytes. It either: gets stuck the preparing state the connection gets reset the data is null and is marked as isComplete = true The only way I can get the device to receive the data is by calling cancel on the NWConnection on the server/NWListener end. Here is some sample code I am working with: https://github.com/leogdion/JustBonjour/tree/nwlistener Is this expected behavior that cancel is required?
Ever since 17.4.1 updates to Safari, we are unable to debug our web applications using Safari. Was working perfectly fine before. Safari shows No Inspectable Applications in the Develop -> iPadName menu. We have 3 target iPads (Mini, Air and gen 10) and one iPhone 13 Pro Max, all on iPadOS and iOS 17.4.1, all of them show No Inspectable Applications in the menu. iPad Mini and iPhone were both visible fine before the 17.4.1 update. Other devices were already updated automagically to 17.4.1 so we couldn't check the before - after scenario. Safari running on iPad simulator with XCode 15.2 has same behaviour. We tried debugging with latest version of following MacOS: MacOS Sonoma (Macbook Pro M2) MacOS Sonoma (Mac Mini M1) MacOS Ventura (Macbook Pro i9) All of those have same behaviour: No Inspectable Applications. We tried Safari Tech Preview and iPadOS 17.5 beta 2 and no change. Are we missing something?
SO.... I built an iOS app with StoreKit, and ran it in the simulator. I attached three listeners using SwiftUI hooks: .subscriptionStatusTask() .task, to listen for Transaction.updates and Transaction.unfinished I also added these to My Mac App, same code. All three fired in the iOS app, at the expected points, for every transaction of interest. Great. None of them fired in the Mac app, at the expected points, for the transaction missing in my previous diagram. Not impressed.
Hi, we noticed some issues with our app when it comes to receiving pushs sent when a device was offline. We know that only one push is stored if multiple are received while the device was offline but we got reports of multiple users that aren't receiving any pushs that were sent while they were offline. Reinstalling the App didn't help. We ruled out the third-party providers we used as my first thought was that there was some issues with setting the expiry but it also happens if directly sent over APNs. With a development build and the sandbox APNs I had no issue receiving one push after getting back online. But after reinstalling the production app no push after being offline. Example sent with the Push Notifications Console but I also tested it with curl directly: curl -v --header authorization: bearer ${AUTHENTICATION_TOKEN} --header apns-topic: de.alarm-it-factory.ACC-App-Xamarin --header apns-push-type: alert --header apns-priority: 10 --header apns-expiration: 1721379960 --data '{aps:{ale
I believe the issue is you have previous tokens you have assigned for this device/app combination, and you are also sending notifications to those tokens, which are not being sent to the device, but are still overwriting the previous notification being held in the queue of one, for that specific app on the specific device. In the 2 hours around the time of your reported failed notification above, you have also been sending notifications to (possibly) old tokens for the same device: E06E81DDA4703F0A100B7DBE91E68A3F6ADAEE2F3CDA4B05FC1BC8813FD7C825 667FCD43E6705C348A237640204D69022F783A435936BD222FD665D49F92718F But after reinstalling the production app no push after being offline. Possibly can be explained with this finding. After reinstalling the app, you are getting a new token, but are not deleting the old token from your database, which ends up getting notifications sent to the old token which is overwriting the queue and losing the notification to the new token if the device is offline at
That's an information message telling you what you can do in Business section. Maybe you just have nothing to do ? Усі країни та: that may relate to the countries where you distribute your apps, you may miss some information there. Could you tell what is the content of action pending ?
Greetings, for the past 2+ weeks I have been going back and forth with the Apple Review team regarding the App Completeness rule. We are using React-Native-IAP package for our in-app purchases and have an issue where in the development environment using sandbox user the purchases show up without issues however when the project goes to review the review team is unable to see these purchases. We have tried explaining that you need to use a physical device as react-native IAP purchases do not work on simulators but have not reached a resolution. For example if we make a production build and run it on a physical IOS devices with sandbox users the purchases show up without issues. Can anyone advise what should be done, so it goes through the review? Even if you do not use react-native any help is welcome! Because this is devastating.
Hello, My app got rejected for the following reason: Guideline 2.1 - Performance - App Completeness We found that your in-app purchase products exhibited one or more bugs when reviewed on iPad running iOS 14.3 on Wi-Fi. Specifically, we were unable to complete IAP transaction. Next Steps When validating receipts on your server, your server needs to be able to handle a production-signed app getting its receipts from Apple’s test environment. The recommended approach is for your production server to always validate receipts against the production App Store first. If validation fails with the error code Sandbox receipt used in production, you should validate against the test environment instead. When I test the purchase on test flights it works just fine so I don't understand what should I do if on my end it works but the apple review saying it doesn't on their side?
Our app has a feature that sends notifications to the user's friends. This app has been declined several times and we are still seeking a solution to publish this app with the sending notification feature. Guideline 5.1.2 - Legal - Privacy - Data Use and Sharing The app appears to spam, phish, or send otherwise unsolicited messages to users or a user’s contacts. Specifically, the app allows the sending of mass text or notification. Spamming users or a user’s contacts in this manner is not appropriate. The app should not mine, trace, harvest, or otherwise maliciously exploit users’ data or other user information to promote your service. Next Steps To resolve this issue, please remove this feature from the app. Our app specification: A user can send the notifications to at most 10 friends at the same time There is an hour limitation to send notifications as an anti-spam measure. There is also a day limitation. UserA can search UserB by its userId, add UserB as an friend and sends the notification without UserB
AFAICT URLSession has no TFO support. Speaking personally, TFO seems like a bit of a dead end to me, and if you’re interested in HTTP performance than HTTP/3 (on QUIC) is the way forward. However, if there’s a specific reason that TFO is critical to your product then you should file an enhancement request explaining that. Please post your bug number, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com
It has been three weeks, and I've lost faith that they can solve it. The problem that bothers me most is that I couldn't reach/find anyone from the technical level support team who knows about these important concepts. I know these programming areas are not very popular, but I think they are still important, and you have to keep some people in the support teams who are knowledgeable about these types of projects.
Hi, I have a PCI DriverKit System Extension project that our team has tested, and the entitlements are not a problem. Once we decided to place the project to the Apple Store the review team requested to add App Sandbox entitlement to the project. Then I added the entitlement manually to the .entitlements file ( I couldn't do that using the Xcode add entitlement section because since it is a driverkit project, the App sandbox is not visible in the entitlements page ) and re-packaged the project for distribution. Later on, I saw that the entitlement was removed during the packaging process. I also tried to add that using the build settings page in Xcode (the signing section ), but I had no luck. I feel like I'm being misled by the review team. Do you know if the App sandbox entitlement is applicable to a DriverKit project ?