Posts

Sort by:
Post not yet marked as solved
0 Replies
1 Views
Guideline 5.2.3 - Legal Your app contains content or features that may violate the rights of one or more third parties. Specifically, your app provides potentially unauthorized access to third-party audio or video streaming, catalogs, and discovery services. Your app and its contents should not infringe upon the rights of another party. In the event your app infringes another party’s rights, you are responsible for any liability to Apple because of a claim.
Posted
by
Post not yet marked as solved
0 Replies
8 Views
I've been investigating an issue with the SO_OOBINLINE socket option. When that option is disabled, the expectation is that out-of-band data that is sent on the socket will not be available through the use of read() or recv() calls on that socket. What we have been noticing is that when the socket is bound to a non-loopback address (and the communication is happening over that non-loopback address), then even when SO_OOBINLINE is disabled for the socket, the read()/recv() calls both return the out-of-band data. The issue however isn't reproducible with loopback address, and read()/recv() both correctly exclude the out-of-band data. This issue is only noticed on macos. I have been able to reproduce on macos M1, following version, but the original report which prompted me to look into this was reported on macos x64. My M1 OS version is: sw_vers ProductName: macOS ProductVersion: 14.3.1 BuildVersion: 23D60 Attached is a reproducer (main.c.txt - rename it to main.c after downloading) that I have been able to develop which reproduces this issue on macos. When you compile and run that: ./a.out it binds to a non-loopback address by default and you should see the failure log, resembling: ... ERROR: expected: 1234512345 but received: 12345U12345 To run the same reproducer against loopback address, run it as: ./a.out loopback and that should succeed (i.e. no out-of-band data) with logs resembling: ... SUCCESS: completed successfully, expected: 1234512345, received: 1234512345 Is this a bug in the OS? I would have reported this directly through feedback assistant, but my past few open issues (since more than a year) have not even seen an acknowledgement or a reply, so I decided to check here first. main.c.txt
Posted
by
Post not yet marked as solved
0 Replies
10 Views
i installed @react-native-firebase/firestore in my react-native project, i changed my podfile as i did previously when i installed Firebase for push notifications, now i'm trying to store my fcm token in Firestore and while building the app i got this error Framework 'FirebaseFirestoreInternal' not found . but i have installed it, its in my podfile : pod 'Firebase', :modular_headers => true pod 'FirebaseCoreInternal', :modular_headers => true pod 'GoogleUtilities', :modular_headers => true pod 'FirebaseCore', :modular_headers => true pod 'FirebaseFirestore', :modular_headers => true pod 'FirebaseCoreExtension', :modular_headers => true pod 'FirebaseFirestoreInternal', :modular_headers => true and even in my podfile.lock - FirebaseFirestoreInternal (10.24.0) . those first 4 lines had no issue, i successfully installed and tested push notifications but this FirebaseFirestoreInternal got some problem, i don't know why, can anyone help?
Posted
by
Post not yet marked as solved
0 Replies
12 Views
Hey everyone, I've noticed a recent issue in my app where users are not receiving automatic updates/ blank push to the pass added to the user wallet. Instead, they have to manually refresh the pass by dragging down the back of the Apple Wallet to see any updates. This might be because the blank push notification is not updating the passes. If you've encountered this problem or have any insights into what might be causing it, I'd love to hear from you. Your feedback is invaluable to me.
Posted
by
Post not yet marked as solved
1 Replies
15 Views
I need to use the Network Link Conditioner tool to test an issue with possibly dropped packets. However, all links on google say you need to download "Additional Tools for XCode" - but the links just go to the developer downloads home page, and the option isn't available anywhere on there. Likewise, "Xcode -> Open Developer Tool -> More Developer Tools..." just goes to the same location. It seems like the download has either been removed, or moved elsewhere - how do we get this tool now?
Posted
by
Post not yet marked as solved
0 Replies
19 Views
I connect two AVAudioNodes by using - (void)connectMIDI:(AVAudioNode *)sourceNode to:(AVAudioNode *)destinationNode format:(AVAudioFormat * __nullable)format eventListBlock:(AUMIDIEventListBlock __nullable)tapBlock and add a AUMIDIEventListBlock tap block to it to capture the MIDI events. Both AUAudioUnits of the AVAudioNodes involved in this connection are set to use MIDI 1.0 UMP events: [[avAudioUnit AUAudioUnit] setHostMIDIProtocol:(kMIDIProtocol_1_0)]; But all the MIDI voice channel events received are automatically converted to UMP MIDI 2.0 format. Is there something else I need to set so that the tap receives MIDI 1.0 UMPs? (Note: My app can handle MIDI 2.0, so it is not really a problem. So this question is mainly to find out if I forgot to set the protocol somewhere...). Thanks!!
Posted
by
Post not yet marked as solved
0 Replies
18 Views
Hello, I have an app with two AppIntents. I invoke first AppIntent with my voice command, then I would like invoke the second AppIntent after the first one. I have implemented the necessary return type for the first AppIntent. My first AppIntent is invoked and executes successfully, however when it calls the second AppIntent, everything inside perform() method in the second AppIntent works but Siri dialog. Siri doesn't say the dialog in the second AppIntent. Below implementation details for my two AppIntents together with AppShortcutsProvider. I appreciate any help. struct MyFirstAppIntent : AppIntent { static let title: LocalizedStringResource = "Show My Usages" func perform() async throws -> some ProvidesDialog & OpensIntent { let dialogStr = IntentDialog(stringLiteral: "You have a package") print("I'm in first AppIntent") return .result(opensIntent: MySecondAppIntent(), dialog: dialogStr) } struct MySecondAppIntent: AppIntent { static let title: LocalizedStringResource = "Show My Usages" func perform() async throws -> some IntentResult & ReturnsValue<String> & ProvidesDialog { print("I'm in second AppIntent") return .result(value: "Listing Packages", dialog: "You have activated Default") } struct MyVoiceShortcutProvider : AppShortcutsProvider { @AppShortcutsBuilder static var appShortcuts: [AppShortcut] { AppShortcut( intent: MyFirstAppIntent(), phrases: ["Call my first intent \(.applicationName)"] ); AppShortcut( intent: MySecondAppIntent(), phrases: ["Call my second intent \(.applicationName)"] ); } }
Posted
by
Post not yet marked as solved
0 Replies
23 Views
We are developing an app which connects to a BLE peripheral in the background whenever it gets close to it. What we have used so far is that we monitor a circular region. When the phone enters the region the app will start scanning for peripherals and when it discovers the peripheral it connects to it. This worked pretty well for the last few iOS versions, perhaps iOS 14-16. It wasn't perfect but for the most part it would feel like it connected rather quickly when you would approach the BLE peripheral. If you listen to music via BLE or talk to someone using your BLE headset then it could sometimes work noticeably worse. But, as said, for the most part it would work satisfactory. Starting with iOS 17 and analyzing the functionality over the past 6 months or so we've noticed a clear worsening of it. It does generally connect to the peripheral but the user might often have to wait for quite some time. Rather frequently the user must even light up the screen of the phone before anything even happens. It appears that some sort of resource allocation, battery saving feature or similar has affected this functionality greatly. The time difference between entering a region and physically approaching the device is generally around 2-3 minutes. We have tried to do it more in line with documentation and follow the guidelines that we find in: https://developer.apple.com/library/archive/documentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/CoreBluetoothBackgroundProcessingForIOSApps/PerformingTasksWhileYourAppIsInTheBackground.html So in doing this we do not start scanning for peripherals when a region is entered, but instead we directly invoke connectPeripheral:options:. This way we offload to the system that we want to connect to that peripheral. However, when testing this we see no real improvement. Sometimes it connects satisfactorily. Sometimes it doesn't really connect at all. Many times it connects if the user lights up the screen. So just looking at what the user is experiencing our analysis is that doing it this way works even worse than what we previously did. I understand that the system has many resources to consider and that some may have to wait while others perform things. But are there any documentation on what one could expect from initiating a connectPeripheral:options: from the background? In the link I posted it simply states the iOS device will reconnect when the user returns home. So not much detail in terms of performance which is crucial for our application. If there aren't any further details on the performance, are there any other ways to improve this functionality? We are not looking at draining the battery whatsoever but we simply need our background running app to be as responsive as possible for a few minutes after it has been launched by the region monitoring. We understand that battery life is important but since this happens rarely and sparsely (not more than a few times per day) it seems reasonable that there should be a way to be able to make it function properly.
Posted
by
Post not yet marked as solved
0 Replies
21 Views
This was mentioned in another thread 4 years ago: This whole discussion assumes that every network connection requires a socket. This isn’t the case on most Apple platforms, which have a user-space networking stack that you can access via the Network framework [1]. [1] The one exception here is macOS, where Network framework has to run through the kernel in order to support NKEs. This is one of the reasons we’re in the process of phasing out NKE support, starting with their deprecation in the macOS 10.15 SDK. Is macOS still an unfortunate exception that requires a socket per Network framework's connection?
Posted
by
Post not yet marked as solved
0 Replies
13 Views
I am getting following message after accepting the agrrement "Your enrollment in the Apple Developer Program could not be completed at this time." This is consistent and i have not been able to bypass this. I added enough money in my bank account as i though that could have been the issue.
Posted
by
Post marked as solved
1 Replies
30 Views
Initially, my task was to determine which type of connection is being used at the moment: 5G or 4G. And I found "CTTelephonyNetworkInfo().serviceCurrentRadioAccessTechnology" but there is a problem when the device has more than one sim. My iPhone has two sims, one physical and one electronic. I need to determine which one is used to access the network. I tried to use "CTTelephonyNetworkInfo().serviceCurrentRadioAccessTechnology" but it is a dictionary [String: String] that only indicates the connection of each of the cards, and it is not possible to find out which one is active from this dictionary. So how can I determine which of the two cards are currently being used to access the Internet?
Posted
by
Post not yet marked as solved
0 Replies
23 Views
We are facing an issue on Catalyst when building our app using Xcode 15.4. The issue is related to precompiled frameworks and seems to be widespread as it happens with multiple vendors (like Firebase or Braze). We are using SPM to add these dependencies, for instance: .package(url: "https://github.com/braze-inc/braze-swift-sdk", from: "8.2.1"), When building, we get the following error: clang:1:1: invalid version number in '-target arm64-apple-ios10.15-macabi' Our macOS deployment target is 12.3. Our iOS deployment target is 15.4. I will try to create a reproducer I can share but I wanted to share this in case there's a known workaround. Thanks in advance!
Posted
by
Post not yet marked as solved
0 Replies
20 Views
Hello, Element with position: fixed; bottom: 0; code is being cut on iPhone Safari Preview mode, when application snippet is present. Clicking “x” or scrolling down repairs it. I am not quite sure how to fix and develop it. Fixing this bug is very problematic, since this preview mode is not possible to recreate on Mac/PC.
Posted
by
Post not yet marked as solved
1 Replies
22 Views
Hello fellow developers, I’ve been working with the CallKit framework in iOS, specifically handling incoming calls. One issue I’ve encountered is that Siri when "read caller name" is enabled announces the caller name/surname set via localizedCallerName and then reads the generic handle value (usually alphanumeric) too! Has anyone encountered a similar situation or if there’s a solution to prioritize the localizedCallerName over the generic handle value without using CXHandleType.emailAddress? Alternatively, any insights or workarounds you know would be greatly appreciated. TLDR: even when I correctly configure the localizedCallerName property, Siri persists in reading the CXHandleType.generic. The original Implementation with CXHandleType.generic: The issue arises when using CXHandleType.generic for alphanumeric IDs (or even URLs as stated by documentation https://developer.apple.com/documentation/callkit/cxhandle). Despite correctly setting the localizedCallerName, Siri continues to announce the generic handle value. Expected Behavior: Siri should read only the localizedCallerName when set and ignore the generic handle value when announcing incoming calls. Workaround: Currently, the only workaround is to use CXHandleType.emailAddress for alphanumeric IDs. However, this is not ideal since it repurposes an email-related handle type for a different purpose. Steps to Reproduce: Create a CallKit app that handles incoming calls (example app from documentation can be used too). On incoming call create CXCallUpdate object Create a CXHandle with CXHandleType.generic and an alphanumeric value (e.g., “ABC123”). Pass the CXHandle to the CXCallUpdate objects' remoteHandle. Set the localizedCallerName property of the CXCallUpdate object with a custom caller name/surname. Report the call with reportNewIncomingCallWithUUID Observe that Siri reads both the localizedCallerName and the generic handle value during call announcements. While we are here a Feature Request: Developers should be able to provide a user-friendly caller name without resorting to workarounds like using CXHandleType.emailAddress. I kindly request that Apple consider enhancing Siri’s behavior in the following ways: Allow developers to suppress the reading of generic handle values while still using the correct handle type. Introduce additional type options for call announcements that don't read the generic value. Both of the above. Thank you for your help! 🙌
Posted
by
Post not yet marked as solved
0 Replies
16 Views
I am trying to develop website that can upload instagram story from web. I opened the Instagram app and even opened the story upload pop-up. but, I can't send Image Data. I need your Help.... source_application is detected at instagram, but backgroundImage is not sent at instagram. How can I send....... because
Posted
by
Post not yet marked as solved
0 Replies
25 Views
We’re looking forward to completing our review, but we need additional information about your app's cryptocurrency exchange services. This information is required to review the app for compliance with App Review Guideline 3.1.5(iii), which requires exchange services only be offered in countries or regions where the app has appropriate licensing and permissions to provide a cryptocurrency exchange. Next Steps Please provide the following information and/or documentation: Confirm in which specific countries or regions you intend to make your app's cryptocurrency exchange services available. Provide documentary evidence of the licensing and permissions for the cryptocurrency exchange services in your app for all of the countries or regions where your app is available. The documentation you provide should indicate where you intend to distribute your app. Provide links to government websites that display the licenses you've secured to provide exchange services in all the countries or regions where your app is available. Provide information on the third-party exchange APIs that your app connects with, including links to public APIs and documentation of partnership with specific third-party exchanges. Do the cryptocurrency exchange transactions occur between the users and the exchange(s) or do you, as the developer, handle the transaction requests with the exchange(s) directly? Are the cryptocurrency exchange features provided in your app decentralized, centralized, or a mix of decentralized and centralized exchange features? Does your app offer new or exclusive tokens or cryptocurrency to users? If so, which ones and on which exchanges can users obtain the currency? Explain the precautions you've taken to comply with anti-money laundering ("AML") and Know Your Customer ("KYC") requirements. If you intend to distribute your app in the United States, provide a copy of your Money Services Business (MSB) registration. Additionally, confirm that you will restrict your app's availability to the states listed on your MSB registration. I'm so confused about this. The reviewer has mention about cryptocurrency exchange services. We enrolled as an organization, in our app doesn't provide cryptocurrency exchange. We just provide decentralized application for users to easily interact with our smart contracts. Basically, all transactions calling smart contracts are generated by our DApps and presented to the users for further verification (meta mask, trust wallet etc) before being sent to the blockchain. So, our app doesn't have any control of user crypto assets. I have no idea. If we need licensing and permissions for the cryptocurrency exchange services. Because, we don't provide cryptocurrency exchange in our app. Am I missing something? anyone can help me to explaine for this case? Thanks
Posted
by
Post not yet marked as solved
1 Replies
29 Views
My App has beed rejected for not complying with the Criminal Activity Reporting Guideline 1.7. I have to provide a documentation showing partnership with local law enforcement (where ever the app is used). Here's the response i got: We noticed that your app allows users to report criminal activity, but we need additional information before continuing our review. Specifically, it is unclear if you have partnered with local law enforcement to respond to the reports of alleged criminal activity. To provide users a safe and reliable experience, apps may only be used to report criminal activity in locations where you have the active involvement of local law enforcement. Next Steps To ensure that your app is partnering with the appropriate institutions, you must provide documentation or evidence of your relationship with local law enforcement wherever your app is distributed. Please attach the documentation in the App Review Information section of App Store Connect. Once you have shared this documentation, we will proceed with our review and will let you know if there are any further issues. Resources Learn more about our requirements for ensuring user safety in App Review Guideline 1.0 - Safety. My App provied a list of police, ambulances, etc to use for emergency purposes only. Not allow users to report anywhere! Please help!
Posted
by

TestFlight Public Links

Get Started

Pinned Posts

Categories

See all