I am currently trying to show Routes in my app, but I get [UserSession] maps short session requested but session sharing is not enabled in the console.
I separated the MapView and calculation of the route in different structs / classes, so that might be the reason. I never heard of the UserSession
[UserSession] maps short session requested but session sharing is not enabled
I have seen people online say this is a bug in iOS 15 / Xcode but I have not found any solution or explanation for what this error means.
Please note that I am also receiving the same error with Mac OSX BigSur and XCode 13.2, so I performed a test with a VM running Mac OSX Catalina:
https://github.com/myspaghetti/macos-virtualbox
Then I downloaded, installed and ran XCode 12.4,
https://xcodereleases.com/
When I built a MapKit / CoreLocation application (see https://www.youtube.com/watch?v=YtYEGsi2HB4), it ran fine on OSX Catalina but I got the same error as above on BigSur. Hopefully, Apple will fix this issue soon with an update.
UPDATE:
It appears that Apple is deprecating their Apple Maps with their Main.storyboard designer because I have a colleague who used Apple Maps without a problem but that was using SwiftUI which has no UI designer--instead everything is specified in code for the UI.
Related
I have submitted a Tizen smart-TV application to the Samsung store, and during the testing process they found that it doesn't start when installed in 2015 devices (it works in modern TVs).
The application was developed in Tizen Studio with TV SDK 4.0, and the minimum compatible platform version is set in the config.xml to Tizen 2.3 (both values apparently compliant with this compatibility table).
Samsung's feedback is the same for 15TV_STANDARD1, 15TV_STANDARD2, and 15TV_PREMIUM model groups: "Blank screen on launching the app."
Any clue about what can be happening with those TV models? Is there any feature that could be causing the crash?
Without more information is difficult to know what may cause the problem with 2015 TVs.
Your best option would be to debug your application on a 2015 model, although I understand this can be difficult.
One thing you can do is to check the Web Engine Specifications and see the differences between the working and non-working models.
Blank screen most likely just means, that your application died somewhere during the initialization.
Did you by any chance use the getDuid() API during initial application initialization? I has some trouble with that if the display has never been connected to the web, so it threw an exception on that call.
Otherwise, assuming the profile is indeed 2.3, then it should work.
I've finished working on a Cocoa (not iOS) application with Swift 3. I've tested it on a desktop computer. It works fine. I've tested it on another desktop computer. It works fine. I have even managed to send it over to iTunes Connect. But I have not submitted it because the same application fails to run on a MacBook Pro (2013). Anyway, I've tested it on a MacBook Pro with a retina display. That's when the entire problem started happening. Actually, this desktop application ran on the same MacBook Pro a few days ago. I think it was not sandboxed yet. Now, every time I send a binary copy that runs on different iMac models to MacBook Pro through AirDrop and try to run the application, I get an error that says EXC_CRASH (Code Signature Invalid). So I've deleted some files inside Developer /Xcode / DerviedData. Now, I cannot even debug the application. When I debug it, it hangs up with a fatal error message, which I have never seen before.
Now, if I double-click on an application that Xcode has generated, I get a crash report that says Library not loaded: #rpath/libswiftAppKit.dylib. I thought that I might have deleted some system files by accident. But if I debug existing macOS and iOS apps, I have no problem running them. Fortunately, the entire problem occurs on this particular Xcode project.
One topic that I've found here suggest that we set the Always Embed Swift Standard Libraries option to Yes. I've done that with no vail. I have also read a suggestion that says something about setting the When using this certification option on a developer certificate to Use System Defaults, which doesn't help. Another suggestion that I've tried is clearning cache (Command + Shift + Option + K).
If you have any suggestions, please let me know. Thanks.
More information
I have also seen a bizarre alert message repeatedly on MacBook Pro that says "%#" cannot be found. This error message poped up when I double-clicked on the application icon. It may refer to
String(format: NSLocalizedString("whatever", comment: ""), variable name)
I have solved the problem! I had the same problem with you. But from the answer in https://www.reddit.com/r/swift/comments/4nac9s/using_swift_frameworks_with_command_line/, I have known that the key is the rpath.
So I try to add this path to the project in the following two settings:
${DT_TOOLCHAIN_DIR}/usr/lib/swift/macosx/
Runpath Search Paths
Library Search Paths
I don't know why need to add both the two settings, but it works!
I currently have an application that uses location services and is working great on devices running iOS5 and above. However, have been running into inconsistency issues with 4.3.x.
Problem:
When installing and running the app for the FIRST time, we get the usual 'Allow this app to use Location Services' dialogue to change the [CLLocationManager authorizationStatus]. However, when we uninstall the application (from the home screen) and reinstall the app, we never get this prompt again and somehow the OS has cached the users response for this app, despite this app being uninstalled and reinstalled freshly. On all other versions of iOS, we get the prompt as expected and the [CLLocationManager authorizationStatus] is set to kCLAuthorizationStatusNotDetermined as expected.
Can anyone tell me why with 4.3 the OS seems to remember the options for the app despite it being uninstalled? In order to rectify this issue currently, I have to manually reset all Location Services settings on the device through the settings menu.
If you need any information, or code snippets, please ask.
It turns out this is a 4.3 limitation and is apparent when running an application on any device iOS 4.3.
Apple must have decided this isn't a bug - which is strange seeing as when a user uninstalls an application, why does the OS remember that users selection of permission for a particular app?
No valid workaround available. Just have to live with it.
I realize this is a stretch and I can't give much info to help but I am reaching for anything. My App has been under continuous development for 3 years and never seen anything like this. I recently submitted a small point release to Apple for Release, and twice now it has been rejected for Crashing on Launch on ALL their devices?
The Crash reports point to some code in static library but the key lines are not getting symbolicated. Tried Atos no luck.
The key point is that I have 7 devices I have tested the app on in every mode I can think of, in particular no connection to anything: Wifi-OFF, AirplaneMode-ON, Location services-OFF. I can NEVER simulate what they claim to be seeing, which is App crashes on launch every time?!
I found one report in the AAPL Dev Forums that sounded similar, but he never got any explanation as to what was up. After he submitted an app with loads of logging in it out of desperation and asked them to send the logs. They got that version and... approved it in hours.
Anyone have ANY ideas. I NEED to get this release out.
NOTE: Resolved
This turned out to NOT be a weak link issue. We only saw the crash when running the App using Ad Hoc distribution of the Archive version as Brad suggested... so that was helpful.
However the resolution turned out to be some compiler flags which I listed here:
https://stackoverflow.com/a/10302012/754494
I'll repost and expand upon my comment from above so that this question can have an accepted answer.
I recently came across a case similar to this when building my GPUImage framework. It appears that the build process is slightly different when archiving than when building and directly installing an application on the device via Xcode.
This can be exposed by building and archiving the application, then choosing to distribute it for ad hoc or enterprise distribution. Take the .ipa and place it in iTunes and manually load it on one of your test devices that way. The behavior of an application prepared in this manner may differ from one built and installed through Xcode, and should be closer to how a build submitted for review will act.
In my case, the problem was due to a lack of proper weak linking. On SDKs newer than iOS 4.3, you should no longer need to weak link whole frameworks if you wish to conditionally use classes and functions that are present in newer SDKs but missing in older ones. If you target 4.0 and higher, the linker should now perform class- and function-level weak linking.
However, this was failing for people using my static library, which does runtime checks for the presence of the new texture cache functions in iOS 5.0, but it only failed in these archived builds. I never saw it in all my testing against 4.x devices, because that was done by installing via Xcode. In the end, I needed to have users explicitly weak link the entire Core Video framework in order to get applications using this framework to run properly when archived and installed via iTunes.
Note that this wasn't due to the Release vs. Debug build configurations, because I tried switching between these in my build schemes when deploying to the device through Xcode and it made no difference there. Something else is different in the way that archived applications are built and linked.
Dear Scholars.
I have created a simple application using the latest SDK (4.2.1), Which runs smoothly and error free on all devices with iOS 4.x.x.
Lately I am getting some comments from users with older iOS version complaining the application is crashing on start, on Apple's crash log I see nothing at all.
Pushing my investigation forward, the only suspect I have at the moment is the use of EventKit class, which if memory serves, where introduced only after iOS4.
I am using it very lightly in one of my classes, and it works perfectly on iOS4.2.1
#import <EventKit/EventKit.h>
//some time later
[self setADateInCal: [MyTimeArray objectAtIndex:0] :formatterDate];
Thus my Questions:
Can this be the issue that crashes my application on iOS < 4 ?
How can I prevent it without dropping the feature for people with iOS4
In general, How can I test this? I have the latest official iOS on my device and SDK, the simulator is limited to how back it can go in regrading to iOS version... any magical way to do so?
1.) Yes. If it wasn't in the API in <4.0 than anyone not running >4.0 will crash.
2.) Test to see if the class is available using NSClassFromString (Google for examples) and respondsToSelector in correspondence to see if the method you want is available to use in the OS version the client is running. You will also probably need to weak link the EventKit framework (again Google for how to do this).
3.) The only real way to test this is to keep a device at the OS you want to test. Personally, I have an old iPhone that I never update running 3.1.3 for things just like this. Alternatively, you can keep old installs of xcode+iOSSDK on different partitions or something and use their simulator. (for future updates i guess since you obviously haven't done this for <4.0). But no, there is no magical way to do this. sorry.
edit for clarity on Number 2: Basically you will check to see if the class/method you want is available on the OS version you are currently running, if it is you can use it, if not you will have to find a work around (omit completely or do it another way that is compliant with older versions).
Yes it could be causing the crash. Issues with missing libraries do not report anything in the apple crash log.
To prevent it from happening you need to do two things,
Weak link the event kit library in xcode.
Check for its existence in your code with something like
,
if(!NSClassFromString(#"EKEventKit")){
//do stuff with event kit
}
The only way to test on the actual iOS version is to get hold of a physical device running ios < 4.