Posts

Post marked as solved
2 Replies
3.6k Views
I am working on an Apple M2 Pro, MacOS Sonoma 14.3.1. Today Xcode automatically updated from 15.2 to 15.3 and downloaded the new 17.4 simulators and runtime tools. I can no longer run my apps in simulator. On Xcode 15.2, there was an option to choose the destination architecture, under Product -> Destination -> Destination Architectures -> Rosetta (the one I have ben required to select in order to run apps for the last few versions). On Xcode 15.3, the option to chose the destination architecture is now missing. I am still able to build successfully to my phone directly. I am unable to build to a simulator, I get the same error for regarding a linker error failure. I have tried: reboot laptop delete information stored in derived data delete local Podfile.lock delete Pods folder pod install reopen xcode run on device - works! run on 17.2 simulator - fails with error run on 17.4 simulator - fails with error Our Podfile looks like this: require_relative '../node_modules/@react-native-community/cli-platform-ios/native_modules' require_relative '../node_modules/react-native-permissions/scripts/setup' platform :ios, '13.4' prepare_react_native_project! setup_permissions([ 'AppTrackingTransparency', 'Camera', 'LocationAlways', 'LocationWhenInUse', 'Notifications', ]) target 'myapp' do config = use_native_modules! # @react-native-firebase/app requirement: use_frameworks! :linkage => :static $RNFirebaseAsStaticFramework = true use_react_native!( :path => config[:reactNativePath], # to enable hermes on iOS, change `false` to `true` and then install pods :hermes_enabled => false ) # Pods for GoogleMaps on iOS rn_maps_path = '../node_modules/react-native-maps' pod 'react-native-google-maps', :path => "#{rn_maps_path}" pod 'react-native-camera', path: '../node_modules/react-native-camera', subspecs: [ 'BarcodeDetectorMLKit' ] pod 'RNSquareInAppPayments', :path => '../node_modules/react-native-square-in-app-payments' target 'myappTests' do inherit! :complete # Pods for testing end # Enables Flipper. # # Note that if you have use_frameworks! enabled, Flipper will not work and # you should disable the next line. # use_flipper!("Flipper-DoubleConversion" => "1.1.7") #avoid duplicate symbols for architecture x86_64 for Folly post_install do |installer| react_native_post_install(installer) installer.pods_project.targets.each do |target| if target.name == "RCT-Folly" target.build_configurations.each do |config| config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] ||= ['$(inherited)', 'FOLLY_HAVE_CLOCK_GETTIME=1'] end end end end end I'm open to additional suggestions, at this point, I can't see a way to tell xcode that we need the other build option (like specifying Rosetta which I used to be able to do). Also, if anyone can help me understand why it is doing this, I'm busy on Google, but not finding what I'm looking for, so I wonder if I'm looking for the right things. Thanks so much! Error:
Posted Last updated
.
Post not yet marked as solved
0 Replies
298 Views
Hi There, I'm trying to understand the limitations we may have for an app we are developing. We have a coffee shop app, which would like to offer of a deal - example: a monthly coffee subscription, for $20 you get 10 black coffees for the month which can be redeemed in either our web or mobile apps during the set duration. This is not an in-app purchase, but one that will end up with physical coffee, though it will be received over a period of time. Do we know if it's okay to use a webview to link to the subscription page for managing their coffee subscription (handled outside of IAP as it is a physical good)? They would add their payment info the same way they already do with other integrations like square or stripe payment forms, and then we link them to the actual payment site. I see some things about not even giving the option to show the link or tell the customers what the link is if they want to investigate the option which would be very difficult for the customer to manage. We want a good experience. The guideline itself says "you must use purchase methods other than in-app purchase to collect those payments, such as Apple Pay or traditional credit card entry." Does anyone see an issue with the planned approach? I see the different lawsuits with EPIC and what not and we don't to end up with a rejected app if we can avoid it.
Posted Last updated
.