Compatibility with iOS < 13 projects

[fermoya]

Compatibility with iOS < 13 projects

[fermoya]

Hi @teameh ,

You are using Cocoapods, aren't you? I'm not sure if there's a way to use pods whose deployment target is greater than your project's deployment target. You'd have to create a different target for that.

It doesn't make sense for me to support a lesser iOS version and then do that hack that you mention. I understand your frustration and I'll see if there's something that could please us both.

Nevertheless, have you tried using SPM? You can add SwiftUIPager as dependency in SPM and then use @available(iOS 13, *) in the files you want to use it.

Hope this solves your issue

[teameh]

Hey @fermoya,

Thanks for the quick reply!

I used SPM for SwiftUI packages. And I've wrapped all my classes that reference SwiftUIPager's in @available(iOS 13, *)'s

Adding the module works fine but importing it in the code gives a compiler error about the my project having a lower target than SwiftUIPager's target.

Compiling for iOS 10.0, but module 'SwiftUIPager' has a minimum deployment target of iOS 13.0: 
DerivedData/MyApp-qbarbsp/Build/Products/Debug-iphonesimulator/SwiftUIPager.swiftmodule/x86_64-apple-ios-simulator.swiftmodule

[teameh]

Just make a quick branch to check if it would work to lower the target and that works indeed fine, see teameh@3a65d7b.

But I understand why you wouldn't want to merge that. This can't be the first project to struggle with this. It's a bit weird that this code compiles fine against 10.0 but you can't use it at runtime. Maybe this is something that should be addressed at SPM.

[fermoya]

@teameh , let me make test this over the next days, I'll keep you posted. Thanks for the feedback

I'll probably release a beta version either tomorrow or Saturday. I'll give you a shout to let you know

[teameh]

Cool. I've added a PR of my branch.

[teameh]

Also added a question to SO, maybe somebody ran into this before https://stackoverflow.com/questions/62073570/import-community-swiftui-package-with-13-0-target-in-ios-10-project

[fermoya]

I've taken a look at other SwiftUI libraries out there and none of them do what you require. You happen to be able to import SwiftUI because Apple needs retrocompatibility, but this framework doesn't.

I can't lower the support version just for a specific case. The library is build to work with iOS 13. Realistically, you shouldn't be supporting iOS 10. Most Apps supports 2 major iOS versions, 3 tops.

There's a workaround for you, though. What you need to do is this.

• In Xcode, create a new framework and call it _ MySwiftUITarget_.
• Set development target iOS 10.
• Use SPM to download SwiftUIPager or create a new target in the Podfile and specify platform :iOS, 13:

target 'MyMainTarget'
    platform :iOS, 10
    use_frameworks!

    # my pods
end

target 'MySwiftUITarget'
    platform :iOS, 13
    use_frameworks!

    pod 'SwiftUIPager'
end

• Import SwiftUIPager
• Create your custom views and add @available(iOS 13, *). Don't forget to declare them public
• From your main target, import MySwiftUITarget and use if #available(iOS 13, *) to navigate to the SwiftUI views in your newly created target.

[teameh]

Yeah I agree, this is not something your library should be fixing. Thanks for the workaround!

And yeah, I agree, ideally we would drop everything but iOS 13, but some apps just need to support old iOS versions for some (corporate) reason..

[teameh]

@fermoya just for future readers, I can't get your workaround working. You say that you set the target of the new MySwiftUITarget to 10.0 but trying to compile that gives me:

Compiling for iOS 10.0, but module 'SwiftUIPager' has a minimum deployment target of iOS 13.0

Setting the target of the that MySwiftUITarget proxy framework to 13.0 makes that target compile fine, but compiling the main app gives the same error:

Compiling for iOS 10.0, but module 'MySwiftUITarget' has a minimum deployment target of iOS 13.0

I'm going to try this approach now https://stackoverflow.com/a/62079401/672989

[fermoya]

@teameh can you try changing -framework to -weak_framework as specified here? Just for SwiftUIPager. So where it says -framework "SwiftUIPager" you change to -weak_framework "SwiftUIPager"

[fermoya]

@teameh I just did some work around this. I've added support to XCFrameworks so if you follow the instructions in the README to manually embed the SwiftUIPager you should be able to use it. It's easier that all this workaround, and more maintainable till your employer decides to drop iOS 10, 11 and 12. As it's a binary, you can import it with no error. You'll just need to add if #available(iOS 13, *) when you use it.

You can download the binary here.

Please, let me know if this worked.

[teameh]

Wow, good work. I was just fiddling with that -weak_framework flag when I read your comment.

Thanks for your effort working on this! This works great without having to do anything else 😊.

It's a pity it's not under control of a package manager, but I guess one can't have it both ways 😏.

How did you build this custom binary? Can I build it locally as well?

[teameh]

Oh wait, I think I got it https://github.com/fermoya/SwiftUIPager/pull/50/files#diff-012ac64a56ba35be679c11af459ffc10R285. Cool! What did you need to do to make it suitable for iOS 10.0?

[fermoya]

@teameh its that commit yeah. I just created an aggregate target and added a script to the build phases. So you just have to open SwiftPager.xcodeproj, build and it will generate the xcframework.

I was trying to have it distributed manually and use weak_framework but as it is pre-compiled as a binary, Xcode won’t compile it and will link it with no issue. When archiving, Xcode should automatically keep the slices you need (a.k.a arm64, x86_64...).

So xcframeworks are currently supported in Cocoapods but in that case I can’t distribute the source code so I’d rather keep it as it is. Tomorrow I’ll spend some more time on this, but I think the best way is to leave as it is now.

Did it work then? Could you import the module with no further issue?

[teameh]

Yeah I would also indeed favour the source code over the binary.

Cool. Yes that works with no further issue! 👍

[teameh]

Tomorrow I’ll spend some more time on this, but I think the best way is to leave as it is now.

Maybe I could import the sources with SPM or Cocoapods and add your build script locally in one of the build phases?

[fermoya]

So the script works because I have a project whose schemes target iOS, macOS, ... So if you want to generate you'd need to download the whole repository or at least the Source Code and SwiftUIPager.xcodeproj. Because Cocoapods and SPM just distribute the code.

All this is because you want to be able to see the Source Code and debug it right?

[teameh]

All this is because you want to be able to see the Source Code and debug it right?

And to contribute back 😄 and test the changes that I've made right away in my production app.

Because Cocoapods and SPM just distribute the code.

Ah yeah, of course.

So if you want to generate you'd need to download the whole repository or at least the Source Code and SwiftUIPager.xcodeproj.

That works fine, I've cloned the repo, can work on stuff, test it in the example app and try it out in my main app by building the .framework. All good now, thanks for the effort!

[teameh]

Crap, I should have tested this on my device. Running on a real device gives me the following:

/private/var/containers/Bundle/Application/E0878F7C-365E-4212-8AC9-CEABE7E80F32/MyApp.app/Frameworks/MySwiftUIProxy.framework/Frameworks/SwiftUIPager.framework/SwiftUIPager: 
code signature in (MySwiftUIProxy.framework/Frameworks/SwiftUIPager.framework/SwiftUIPager) not valid for use in process using Library Validation: 
mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed.

This is my structure:

- MyApp
    embeds: 
    - MySwiftUIProxy.framework
        embeds:
        - SwiftUIPager.framework

Both frameworks are set to Embed & Sign:

I needed MySwiftUIProxy.framework as an intermediate to get the SwiftUI previews working. They don't work if I add the SwiftUI code to the main app due to CocoaPods/CocoaPods#9275. Also building the main app target takes some time, so it convenient to have all the SwiftUI code in a separate framework.

[fermoya]

@teameh , yeah I didn't try it in a device either hehe. Can you try changing the Embed options and run? I remember Emebed & Sign isn't the option that Xcode used by default for this xcframework, altho it used Embed & Sign for other libraries like Stripe

[fermoya]

@teameh , it works for me when I run it on my Mac. I only find some issue when running on devices/simulators with iOS lesser than 13. For some reason, setting SwiftUIPager as optional doesn’t seem to work, but I’ve come up with a workaround for that. In any cases, I don’t get the error you get.

Are you generating the xcframework yourself?

[teameh]

I’ll try the other option.

I tried both generating it myself and using you precompiled framework, both seem to fail.

[teameh]

For future readers, this is how I made it work:

1) Astract target in the podfile so the lib is downloaded to /Pods

abstract_target 'SwiftUIPagerProxy' do
    platform :ios, '13.0'
    pod 'SwiftUIPager'
end

2) SwiftUIPager is manually included in XCode project

• Manually drag the content of the Pods/SwiftUIPager/Sources to your XCode project
• Make sure they're compiled with the right target

Don't use "import SwiftUIPager" because there's no framework now, you're just compiling the sources.

When you update the Pod you'll have to re-add the files to your XCode project..

[fermoya]

I've added a branch legacy-projects that decreases the deployment target. I'll be rebasing that branch with every release to support legacy projects. See Legacy Support. You can use your favorite Package Manager.

[teameh]

Thanks. That does sound like a lot of work and also error prone though..

[fermoya]

A GitHub Action has been set to rebase legacy-projects branch and keep it up to date with develop