WebP.framework for iOS does not work with Project Catalyst / UIKit for Mac

184 views
Skip to first unread message

nob...@twitter.com

unread,
Jul 1, 2019, 3:55:12 PM7/1/19
to WebP Discussion
Building an iOS app for Mac with Apple's macOS 10.15 Catalina technology, Project Catalyst, results in failure to link the WebP.framework.

Will likely need to rebuild WebP.framework with Xcode 11 (currently in beta).

Would it be possible to get a drop of WebP.framework built to support iOS apps on Mac?  And to update the iosbuild.sh script?

James Zern

unread,
Jul 1, 2019, 7:53:43 PM7/1/19
to webp-d...@webmproject.org
Hi,

On Mon, Jul 1, 2019 at 12:55 PM nobrien via WebP Discussion
<webp-d...@webmproject.org> wrote:
>
> Building an iOS app for Mac with Apple's macOS 10.15 Catalina technology, Project Catalyst, results in failure to link the WebP.framework.
>

What's the failure out of curiosity?

> Will likely need to rebuild WebP.framework with Xcode 11 (currently in beta).
>
> Would it be possible to get a drop of WebP.framework built to support iOS apps on Mac? And to update the iosbuild.sh script?
>

If you have the beta installed it might be easier to rebuild libwebp
from the 1.0.2 branch using the iosbuild.sh script locally, it doesn't
have much in the way of dependencies (which can be satisfied using
homebrew/ports). We'll be making a 1.0.3 release soon, but in general
we use the latest stable version of the tools for the binary archives.

nob...@twitter.com

unread,
Jul 5, 2019, 2:39:04 PM7/5/19
to WebP Discussion


On Monday, July 1, 2019 at 4:53:43 PM UTC-7, James Zern wrote:
Hi,

On Mon, Jul 1, 2019 at 12:55 PM nobrien via WebP Discussion
<webp-d...@webmproject.org> wrote:
>
> Building an iOS app for Mac with Apple's macOS 10.15 Catalina technology, Project Catalyst, results in failure to link the WebP.framework.
>

What's the failure out of curiosity?

error: Building for UIKit for Mac, but the linked framework 'WebP.framework' was built for <unknown>. You may need to restrict the platforms for which this framework should be linked in the target editor, or replace it with an XCFramework that supports both platforms. (in target 'Sample App')

 

> Will likely need to rebuild WebP.framework with Xcode 11 (currently in beta).
>
> Would it be possible to get a drop of WebP.framework built to support iOS apps on Mac?  And to update the iosbuild.sh script?
>

If you have the beta installed it might be easier to rebuild libwebp
from the 1.0.2 branch using the iosbuild.sh script locally, it doesn't
have much in the way of dependencies (which can be satisfied using
homebrew/ports). We'll be making a 1.0.3 release soon, but in general
we use the latest stable version of the tools for the binary archives.

unfortunately, I do not think this can be addressed just through the iosbuild.sh since it will require clang to build and gcc is how configure appears to build things for webp. 

James Zern

unread,
Jul 8, 2019, 5:53:25 PM7/8/19
to webp-d...@webmproject.org
On Fri, Jul 5, 2019 at 11:39 AM nobrien via WebP Discussion
<webp-d...@webmproject.org> wrote:
>
>
>
> On Monday, July 1, 2019 at 4:53:43 PM UTC-7, James Zern wrote:
>>
>> Hi,
>>
>> On Mon, Jul 1, 2019 at 12:55 PM nobrien via WebP Discussion
>> <webp-d...@webmproject.org> wrote:
>> >
>> > Building an iOS app for Mac with Apple's macOS 10.15 Catalina technology, Project Catalyst, results in failure to link the WebP.framework.
>> >
>>
>> What's the failure out of curiosity?
>
>
> error: Building for UIKit for Mac, but the linked framework 'WebP.framework' was built for <unknown>. You may need to restrict the platforms for which this framework should be linked in the target editor, or replace it with an XCFramework that supports both platforms. (in target 'Sample App')
>

Thanks for adding that. It doesn't add too much detail, so the next
step may be, like you suggested, to try Xcode 11. I didn't check the
changelog for that, but another possibility is that armv7 (not armv7s)
has been dropped which is included in the framework builds.

>
>>
>>
>> > Will likely need to rebuild WebP.framework with Xcode 11 (currently in beta).
>> >
>> > Would it be possible to get a drop of WebP.framework built to support iOS apps on Mac? And to update the iosbuild.sh script?
>> >
>>
>> If you have the beta installed it might be easier to rebuild libwebp
>> from the 1.0.2 branch using the iosbuild.sh script locally, it doesn't
>> have much in the way of dependencies (which can be satisfied using
>> homebrew/ports). We'll be making a 1.0.3 release soon, but in general
>> we use the latest stable version of the tools for the binary archives.
>
>
> unfortunately, I do not think this can be addressed just through the iosbuild.sh since it will require clang to build and gcc is how configure appears to build things for webp.
>

gcc is clang at this point on mac os [1] so if you have the beta
installed it might be worth a shot.

[1] $ gcc --version
Configured with:
--prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin18.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

ben.sp...@driveclutch.com

unread,
Apr 29, 2020, 1:14:52 PM4/29/20
to WebP Discussion
It's been a year, Xcode 11 is no longer beta.  I get the same build failures.  Are there any updates on this?

James Zern

unread,
May 4, 2020, 8:04:22 PM5/4/20
to WebP Discussion
Hi,

On Wed, Apr 29, 2020 at 10:14 AM <ben.sp...@driveclutch.com> wrote:
>
> It's been a year, Xcode 11 is no longer beta. I get the same build failures. Are there any updates on this?
>

Thanks for bumping the thread. The framework released with 1.1.0 was
built using Xcode 11.0. Are you running into the issue using that
framework or one built locally using iosbuild.sh?
If you have instructions on how to reproduce the issue I can try it out locally.

> --
> You received this message because you are subscribed to the Google Groups "WebP Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to webp-discuss...@webmproject.org.
> To view this discussion on the web visit https://groups.google.com/a/webmproject.org/d/msgid/webp-discuss/bb82b133-ad73-4980-9995-b194c5b24caf%40webmproject.org.

ben.sp...@driveclutch.com

unread,
May 4, 2020, 9:05:39 PM5/4/20
to WebP Discussion
I downloaded the libwebp-1.1.0-ios-framework, and dropped the frameworks inside into my project.  Our project does not use cocoa pods.
I got the same error
"Building for Mac Catalyst, but the linked framework 'WebPDecoder.framework' was built for iOS + iOS Simulator. You may need to restrict the platforms for which this framework should be linked in the target editor, or replace it with an XCFramework that supports both platforms."
 for each of WebPDemux.framework, WebPMux.framework, and WebP.framework.

I went to try the Mac build, libwebp-1.1.0-mac-10.15, but there was no .framework bundle inside, and I wasn't in the mood to dig up cryptic docs on where to put include files to try to static link anything.

Just because it's built with Xcode 11, doesn't mean it's built for all platforms.


On Monday, May 4, 2020 at 8:04:22 PM UTC-4, James Zern wrote:
Hi,

On Wed, Apr 29, 2020 at 10:14 AM <ben.sp...@driveclutch.com> wrote:
>
> It's been a year, Xcode 11 is no longer beta.  I get the same build failures.  Are there any updates on this?
>

Thanks for bumping the thread. The framework released with 1.1.0 was
built using Xcode 11.0. Are you running into the issue using that
framework or one built locally using iosbuild.sh?
If you have instructions on how to reproduce the issue I can try it out locally.

> --
> You received this message because you are subscribed to the Google Groups "WebP Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to webp-d...@webmproject.org.

Cem Kozinoglu

unread,
Jul 20, 2020, 3:45:02 PM7/20/20
to WebP Discussion, ben.sp...@driveclutch.com
Hey guys any luck with this?

James Zern

unread,
Jul 20, 2020, 4:13:10 PM7/20/20
to WebP Discussion, ben.sp...@driveclutch.com
On Mon, Jul 20, 2020 at 12:45 PM Cem Kozinoglu <c...@thecatch.app> wrote:
Hey guys any luck with this?

Sorry for the lack of reply on this one. I was working with a mac remotely that I lost access to so I haven't had a chance to take a look at the behavior. When I get that resolved I'll take a look and see if I can address the issue in time for our next release.
 
To unsubscribe from this group and stop receiving emails from it, send an email to webp-discuss...@webmproject.org.
To view this discussion on the web visit https://groups.google.com/a/webmproject.org/d/msgid/webp-discuss/da188d08-c450-4aa8-b06f-cb8d2413f06bn%40webmproject.org.

Nolan O'Brien

unread,
Jul 26, 2020, 11:12:49 AM7/26/20
to WebP Discussion, James Zern, ben.sp...@driveclutch.com
We're now hoping to get a drop of this as well, the integration we had before to just build the raw code for Catalyst no longer works when building for Apple Silicon (using the Apple Silicon DTK).

James Zern

unread,
Dec 10, 2020, 3:38:14 PM12/10/20
to Nolan O'Brien, WebP Discussion, ben.sp...@driveclutch.com
On Sun, Jul 26, 2020 at 8:12 AM Nolan O'Brien <nob...@twitter.com> wrote:
We're now hoping to get a drop of this as well, the integration we had before to just build the raw code for Catalyst no longer works when building for Apple Silicon (using the Apple Silicon DTK).

On Monday, July 20, 2020 at 1:13:10 PM UTC-7 James Zern wrote:
On Mon, Jul 20, 2020 at 12:45 PM Cem Kozinoglu <c...@thecatch.app> wrote:
Hey guys any luck with this?

Sorry for the lack of reply on this one. I was working with a mac remotely that I lost access to so I haven't had a chance to take a look at the behavior. When I get that resolved I'll take a look and see if I can address the issue in time for our next release.

I added xcframebuild.sh [1] which works for me in a trivial example app. I'm not an iOS developer though so if people want to give this a try that would be great. I'll include these builds in the 1.2.0 release.

Liam Nichols

unread,
Oct 19, 2021, 6:19:38 PMOct 19
to WebP Discussion, James Zern, WebP Discussion, ben.sp...@driveclutch.com, Nolan O'Brien
Hi Everbody! 

Thanks James for adding xcframework support, I was able to get this working in Twitter Image Pipeline but I had to make a little tweak to work around an issue that I ran into however it's not immediately clear to me where the issue lies and if its something we can fix (or need to fix?) here.

The issue that i hit was similar to what is described in this thread: https://developer.apple.com/forums/thread/651043

When I include both WebP.xcframework and WebPDemux.xcframework in a project and add link it to a target, i get errors like the following:

error: Multiple commands produce '.../Build/Products/Debug-iphoneos/include/demux.h':

1) Command: ProcessXCFramework .../ios-twitter-image-pipeline/Extended/WebP.xcframework .../Build/Products/Debug-iphoneos/include/decode.h ios

2) Command: ProcessXCFramework .../ios-twitter-image-pipeline/Extended/WebPDemux.xcframework .../Build/Products/Debug-iphoneos/include/decode.h ios


The problem comes because the Headers directory in the xcframework for each version of the library includes files with the same name. When Xcode copies them into the includes directory, they conflict and the build fails. The suggested fix in the thread was to nest the headers in uniquely named directories within the Headers directory and after doing that, it works. 

So in the WebP.xcframework, I move the headers from WebP.xcframework/{platform-archs}/Headers/decode.h to WebP.xcframework/{platform-archs}/Headers/WebP/decode.h and then I am able to import them in Objective C using #import <WebP/decode.h> just like we were doing with WebP.framework in the past.


Now I must admit that I'm not too familiar with xcframeworks and I have no idea if this is the approach that we must take, but I do know that its required in order to use multiple xcframeworks with headers that are named the same. Do you have any thoughts on this? 


There is a bit more context here: https://github.com/twitter/ios-twitter-image-pipeline/pull/66


Thanks for the work so far!
Liam

James Zern

unread,
Oct 19, 2021, 9:19:59 PMOct 19
to Liam Nichols, WebP Discussion
Hi Liam,

On Tue, Oct 19, 2021 at 2:25 PM Liam Nichols <liam.ni...@gmail.com> wrote:
Hi Everbody! 

Thanks James for adding xcframework support, I was able to get this working in Twitter Image Pipeline but I had to make a little tweak to work around an issue that I ran into however it's not immediately clear to me where the issue lies and if its something we can fix (or need to fix?) here.

Thanks for trying it out and the detailed explanation of the problem.
 

The issue that i hit was similar to what is described in this thread: https://developer.apple.com/forums/thread/651043

When I include both WebP.xcframework and WebPDemux.xcframework in a project and add link it to a target, i get errors like the following:

error: Multiple commands produce '.../Build/Products/Debug-iphoneos/include/demux.h':

1) Command: ProcessXCFramework .../ios-twitter-image-pipeline/Extended/WebP.xcframework .../Build/Products/Debug-iphoneos/include/decode.h ios

2) Command: ProcessXCFramework .../ios-twitter-image-pipeline/Extended/WebPDemux.xcframework .../Build/Products/Debug-iphoneos/include/decode.h ios


The problem comes because the Headers directory in the xcframework for each version of the library includes files with the same name. When Xcode copies them into the includes directory, they conflict and the build fails. The suggested fix in the thread was to nest the headers in uniquely named directories within the Headers directory and after doing that, it works. 

So in the WebP.xcframework, I move the headers from WebP.xcframework/{platform-archs}/Headers/decode.h to WebP.xcframework/{platform-archs}/Headers/WebP/decode.h and then I am able to import them in Objective C using #import <WebP/decode.h> just like we were doing with WebP.framework in the past.


Now I must admit that I'm not too familiar with xcframeworks and I have no idea if this is the approach that we must take, but I do know that its required in order to use multiple xcframeworks with headers that are named the same. Do you have any thoughts on this? 


This seems like a reasonable workaround. I'll file a bug to track this and take a closer look at what's expected with xcframeworks.
Reply all
Reply to author
Forward
0 new messages