Has anyone successfully added the Parse tvOS SDK to an existing iOS project with a separate tvOS target?
The iOS app already uses the Parse SDK.
I added a tvOS target to my project, added the Bolts, Parse, SystemConfiguration, and libsqlite3.tbd (got Parse & Bolts here: https://github.com/parseplatform/parse-sdk-ios-osx/releases/tag/1.11.0)
I can compile and run that target on the AppleTV simulator, but I get tons of warnings like this:
URGENT: building for tvOS simulator, but linking in object file
(<path>Parse.framework/Parse(PFObject.o)) built for iOS.
Note: This will be an error in the future
Also, calling PFUser.logInWithUsernameInBackground just hangs.
Not sure if what I'm trying to do just isn't possible of if I'm doing something stupid. Would be great to get this to work as there's lots of sharable code between the projects.
Figured it out. I removed the iOS framework's path from the tvOS target's Framework Search Paths in build settings. The location of the iOS framework appeared first in the list of paths, which I guess hijacked the framework since the iOS/tvOS frameworks have the same name.
Sometimes you just have to take a break and then double check your assumptions.
Related
Kotlin iOS Integration:
KMP is creating a separate shared.framework based on architecture (Simulator/iPhone). Both the frameworks are generated under the Debug directory. As the frameworks search path is set recursive it searches for incorrect framework and throws error and my iOS apps compiling fails.
I am not able to find out which framework to link depending on selected platform Device/Simulator.
Just wanted to know if there is any possible way to handle this issue of multiple frameworks so I can switch between Simulator or Device and the Xcode matches and applies the correct shared.framework
I needed to add /$(CONFIGURATION)/$(SDK_NAME)and make it as non-recursive.
Now even if I run app on simulator and then on actual device, Xcode maps & links correct shared.framework.
This solved my issue.
I'm working on a project that has four targets: an iOS and Mac framework, and an iOS and Mac example application target. The frameworks have identical code, and the example apps are very nearly using the same code (it's a SwiftUI app). I've done this sort of thing before, but now, while my Mac app and Mac framework happily co-exist and work fine, the iOS framework simply can't be found in the iOS example app.
Hoo boy, have I tried everything I can think of.
Yes, the framework is present in the example app's "Frameworks, Libraries..." section under General, and also appears in the Build Phases "Dependencies" as well as "Link Binary with Libraries" sections.
I've tried various values for the Framework Search Paths in Build Settings, though the Mac one has no value for that field and it's fine.
Ditto for Runpath Search Paths. On the Mac it's "#executable_path/../Frameworks", and I've tried that and various others on the iOS side.
The framework builds just fine by itself. I can look at it in Derived Data, and it seems to be there and present. Here's a capture of that folder.
I'm not sure what else to try at this point. I don't know if this is a bug in Xcode 12 Beta, perhaps? Or in Big Sur Beta? Is there anything else I can look at to figure out what's going on?
I am in the process of porting an all iOS + WatchOS 1 app written originally in Swift 1, to the latest Xcode 8, WatchOS 3, Swift 3.
My app has an embedded framework with some common functionality that used to compile and run file for both the watchkit extension target and the ios app target.
With Xcode 8 I can no longer seem to get this to work. When I try to import the framework in the watchkit extension code, I get the module not found error.
Is it still possible to compile and use one single embedded framework package on both the target iOS and WatchKit extension targets? In my framework I have the target platforms set to watchos, watchsimulator, iphoneos, iphonesimulator.
My gut says it's not possible anymore. Where originally all the code really ran on the phone itself, not that codes runs on the actual watch and the phone, you'd need to compile an embedded framework specifically for each.
Short version: You can't. Create a duplicate target and set it to use the watch SDK.
Longer version from Apple's docs: https://developer.apple.com/library/content/documentation/General/Conceptual/WatchKitProgrammingGuide/iOSSupport.html#//apple_ref/doc/uid/TP40014969-CH21-SW1
including:
NOTE
After you create a separate framework target for your WatchKit
extension, you must manage the contents of that framework separately
for both iOS and watchOS. If you add files to the iOS version of the
framework, remember to add them to the watchOS version.
Since Xcode 11 you can use Swift Package Manager to do this without duplicate targets. Have tested in Xcode 12 beta6 at least and it is another option to look at that didn't exist when the question was asked or I initially answered (and it doesn't meet the detailed requirements of the question as it needs newer Xcode).
I just upgraded from Xcode 6 Beta 2 to Xcode Beta 3 and am now getting the following warning when building my project:
ld: warning: relocatable dylibs (e.g. embedded frameworks) are only supported on iOS 8.0 and later (#rpath/libswift_stdlib_core.dylib)
It is a warning but seems to mean my current setup will not work on iOS 7.1, which is my deployment target. How can I track down which frameworks are embedded, and how can I fix this for iOS < 8.0?
This appears to be a bug of Beta 3. As pointed out by Apple Engineer on this post.
I have also been living with this warning when running apps on iOS 7.1 device.
You see and add them on the project page when you select the target: tab General->Embedded Binaries (and they then appear in Build Phases->Embed Frameworks).
Embedded frameworks for OSX were available in Xcode 5, but not for iOS.
WWDC session regarding new features in Xcode 6 specifically promised dynamic frameworks for iOS 8 (someone please add citation when developer center comes back online). So far, with all Xcode 6 betas, I have had no problems compiling and debugging an app with frameworks on iOS 7.
But since this wasn't promised, frameworks for iOS7 is something you cannot depend on (e.g. this may stop working in later betas; an app with embedded framework for iOS 7 may be rejected, etc.). That may explain why they added an explicit warning.
There's not much you can do if this feature turns out to be indeed unsupported, other than remove the frameworks from the target and use static libraries as we did with Xcode 5. Or go the iOS8-only route.
After using XCode 6.1.1 I am able to put the code on iOS 8+ iOS7.1.2 and iOS 6.1.3 Although the warning is still there but the app works absolutely fine on all the 3 OSs
======================
Lucky guy... My project keeps failing to compile after I referenced the PushKit framework.
The project is a new project created by Xcode with only 3 new functions for testing Push Notification.
The workaround is to put the PushKit framework as "embedded", but this is not a good solution since my working Xcode project will be generated from Unity3d. Making the changes manually will break the auto build process.
I had this error after adding a C++ framework (DeepBelief) to a project. Adding an empty .cpp file to the project fixed it.
I'm using Beta4, and found the answer on the DeepBelief github site:
XCode may be skipping the standard C++ library, and that's needed by
the DeepBelief.framework code. One workaround I've found is to include
an empty .mm or .cpp file in the project to trick XCode into treating
it as a C++
project.
Read this github post from ReactiveCocoa
The bug is still present in XCode6 GM and so XCode6 final release:
Well, I get the exact same issue in xcode6GM no matter whether I
create framework for swift OR objc :-[[[[[[[[[[[[[[[
According to Apple Extension Programming Guide:
You can make a containing app available to users running iOS 7 or earlier, but then must take precautions to safely link embedded frameworks when running in iOS 8 or later.
talking about app extensions, but if you read it, you can understand that this applies to embedded frameworks in general.
this is happening because one of your embedded binaries's deployment target is lower than your applications target. lower your embeded binaries's building target and be fine.
this was the error cause in xcode 6.1.1
i was using xcglogger with deployment target ios 8.0, and my application's deployment target 7.0. set the xcglogger's deployment target ios 7.0 and problem solved.
After using XCode 6.1.1 I am able to put the code on iOS 8+ iOS7.1.2 and iOS 6.1.3
Although the warning is still there but the app works absolutely fine on all the 3 OSs
Yes not able to submit the app for review.
Had to do by changing the modern frameworks to Static libs.
I've created a project in Xcode 5.0 (yes, Developer Preview) for the beta iOS7 software because I wanted to play around with the new beta stuff. But I actually decided to submit the App I was playing around with to the App Store and since this is not possible with preview Xcode versions I fixed all compatibility issues to make the code work with Xcode 4.6.3 and iOS 6. Except for one thing.
And that's importing third party frameworks like Flurry (analytics framework) or Crashlytics (crash reporting framework).
Both are correctly imported and set up with targets (it's all working in Xcode 5.0) but I'm getting a 'Crashlytics/Crashlytics.h' file not found in the line I'm importing the needed classes (#import <Crashlytics/Crashlytics.h>) in Xcode 4.6.
The same is true for the Flurry framework analogously. The crazy thing is, both libraries show up in the targets 'Link Binary With Libraries' list, even in Xcode 4.6.
Does anyone have an idea how I can get things work in Xcode 4.6? Are there any further ways to influence the importing?
The link binary with libraries is not the issue here. You have to confirm your Header Search Paths in your build settings. I think Xcode 5 might use a different variable for it, and that is why Xcode 4.6 will get confused (just a guess though). Anyway, confirm that the path to those headers is in your Header Search Path. The Crashlytics app will automatically add it for you, actually.