[BUG] Problem with Xcode 16 Beta

[badepaz]

Describe the bug I get missing header file warnings when building

Exception or Stack Trace N/A

To Reproduce Install Xcode 16 Beta Try to build a project with framework as a swift package dependency See build errors about missing header files ANHASync.h and, sometimes, SBTemplateRegistration.h

Code Snippet N/A

Expected behavior Project to build

Screenshots

Setup (please complete the following information):

• OS: iOS 18.1
• IDE : Xcode 16 Beta 5
• Version of the Library used: 3.15

Additional context This is using the Swift Package version. I opened the project back up in Xcode 15 and built there successfully. Then I returned to Xcode 16 immediately after. And then one of the missing header file errors went away, but one remained. Even after cleaning the build folder, refreshing the swift package cache, updating to the latest versions, it still won't build.

Information Checklist Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

• [x] Bug Description Added
• [x] Repro Steps Added
• [x] Setup information Added

[oleksii-pyvovarov-windmill]

I have the same problem with Xcode 16.1 beta WindowsAzureMessaging is linked via SPM version 3.1.5

[Roberdan]

it's always the same issue with XCode Beta....and I'm even not sure if this repo is maintained anymore....no fixes, no new code... @brannon? Does anyone have found an alternative? thx

[johnmartino]

Unfortunately they are not interested in fixing this while Xcode 16 is in beta. It seems like there was a similar issue last year so hopefully this gets resolved when Xcode 16 is officially released. If not, they will most likely fix it at that point.

It's not ideal, but you could include the framework directly into the project.

[badepaz]

Xcode 16 will only be in beta for 6 more days. The release candidates are always made available the day of the iPhone announcement, which is on September 9.

[learnwithgabbar]

duplicate https://github.com/Azure/azure-notificationhubs-ios/issues/150

[matt-certain-ct]

Xcode 16 will only be in beta for 6 more days. The release candidates are always made available the day of the iPhone announcement, which is on September 9.

This is still a problem with the Release Candidate. There needs to be a more permanent fix.

[badepaz]

Completely agree. If the project were using modern best practices (Apple development best practices), then there shouldn’t be a problem with the framework working just because Xcode is in beta. Sure there could be flukes and weird things in betas. But in general, problems are usually related to API changes or language feature changes. But missing header files because there are scripts that are copying and moving files around… I saw in another issue that someone changed the import statement to “..\ANHAsync.h”. Why the ‘..\’? Because some shell script is probably moving files around in the source code directory. I can’t think of a good reason for this. If you have to substitute different source files because of platform differences, there are preprocessor macros, target memberships, fat binary frameworks, etc. needing a shell script to move things around is like pulling the rug out from under the compiler.

[badepaz]

I should also point out that none of the other frameworks in our project had a single issue with the new Xcode beta.

[johnmartino]

I have the same experience. It's only this framework. I misspoke earlier regarding Xcode 16 beta 4. I thought the issue was resolved somehow but it wasn't. I can't say much, but I am hoping to hear something more concrete on this issue this Friday. Hopefully there will be someone assigned to look at this problem shortly. For now, I cannot move to Xcode 16 unless I abandon SPM for this framework and include it directly, which I will do as a last resort.

[nharbo]

As some says, it's also a problem with the actual Xcode 16 version (non-beta). Would be great if this could be fixed! Anyone has a workaround?

[dannmat]

Also having this problem with the Xcode 16 public release

[badepaz]

We have decided to download the XCFramework and just manually integrate it into the project. Since it’s a precompiled binary, it doesn’t have a problem.

[badepaz]

If you really wanted to use Swift Package Manager, you could always wrap the XCFramework in a Swift Package with a binary target. But this project seems like it’s barely maintained anyway - so it’s not like there are regular releases you have to keep up-to-date with by using a dependency manager; the last release was over three years ago. I would suggest to Microsoft that they just change their Swift Package Manager and Carthage distribution to use a binary framework. If the source code isn’t going to be maintained, then at least with a binary framework there won’t be compilation issues.

[venzii08]

I'm having the same issue, for me SBTemplate

after I updated Xcode 16. I tried all possible way by changing the header and folder path but doesn't work at all :/

[nharbo]

We have decided to download the XCFramework and just manually integrate it into the project. Since it’s a precompiled binary, it doesn’t have a problem.

Did you have to do anything with the xcframework to make this apply? I'm getting an error:

local binary target 'WindowsAzureMessaging' at '.../notifications/Frameworks/WindowsAzureMessaging.xcframework' does not contain a binary artifact.

EDIT: I rebuilt the xcframework and now it works :) Thank you!

[venzii08]

We have decided to download the XCFramework and just manually integrate it into the project. Since it’s a precompiled binary, it doesn’t have a problem.

Did you have to do anything with the xcframework to make this apply? I'm getting an error:

local binary target 'WindowsAzureMessaging' at '.../notifications/Frameworks/WindowsAzureMessaging.xcframework' does not contain a binary artifact.

EDIT: I rebuilt the xcframework and now it works :) Thank you!

I used the Xcframework, added to the project and added the framework in general tab and signed and embedded. But I couldn't resolve this. It would be great if you could post your solution here :)

Edit: I made it work when you use xcframework you need to remove the package then it works. and add the XCframework to the project (Embed and sign) and the in framework search path provide $(PROJECT_DIR)/path_to_your_xcframework_directory

[dannmat]

@venzii08 @nharbo how do you rebuild the XCFramework? Clone this repo and use xcodebuild archive then import into your project?

[badepaz]

Why are you trying to rebuild it? Just go here, https://github.com/Azure/azure-notificationhubs-ios/releases, download the XCFramework file, drag it into the Frameworks folder in the project, and then link it to your target. I don’t use embedded. I set it to Do Not Embed. You have to remove the old Swift Package Manager dependency before you do the XCFramework though.

[nharbo]

I'm using the SDK in a local Swift package.

I got the error above, but maybe it wasn't needed to rebuild. I did anyway though, also to get rid of the unneeded frameworks for tvOS etc. Here's the command, if anyone needs it:

xcodebuild -create-xcframework \
  -framework /PathToDownloadedFramework/WindowsAzureMessaging.xcframework/ios-arm64_i386_x86_64-simulator/WindowsAzureMessaging.framework \
  -framework /PathToDownloadedFramework/WindowsAzureMessaging.xcframework/ios-arm64_arm64e_armv7_armv7s/WindowsAzureMessaging.framework \
  -output /PathToRebuiltFramework/WindowsAzureMessaging_rebuilt.xcframework

I then changed my Package.swift like this:

// swift-tools-version: 5.7.1
// The swift-tools-version declares the minimum version of Swift required to build this package.

import PackageDescription

let package = Package(
    name: "Notifications",
    platforms: [.iOS(.v16)],
    products: [
        .library(
            name: "Notifications",
            targets: ["Notifications"]
        ),
    ],
    dependencies: [
        // Dependencies declare other packages that this package depends on.
    ],
    targets: [
        .binaryTarget(
            name: "WindowsAzureMessaging",
            path: "Sources/Notifications/Frameworks/WindowsAzureMessaging_rebuilt.xcframework"
        ),
        .target(
            name: "Notifications",
            dependencies: [
                "WindowsAzureMessaging"
            ],
            path: "Sources"
        ),
    ]
)

The rebuild SDK is placed in a folder named Frameworks in my SwiftPackage:

notifications/ <- My local Swift package
├── README.md
├── Package.swift
└── Sources/
    └── Notifications/
        ├── Frameworks/
           └── WindowsAzureMessaging.xcframework

[badepaz]

I think the way they usually prefer you to handle a binary file in a swift package is to zip it. Zip the XCFramework file and then in your binary target path, give the path to the zip file. That’s how apple demonstrated it at WWDC, and it’s how they show it in their documentation. That “does not contain a binary artifact” error happened to me in a framework I’m currently developing. I zipped it up, like in the docs, and the error went away. I’m sure you could probably make it use the XCFramework file directly, but that’s just the way it’s shown in the docs. Don’t ask me why - I have no idea why they have it set up like that. Maybe because the XCFramework is a folder bundle format and zip files are easier to pass around in automated tools. I don’t know.

[badepaz]

But, back to the original issue this is for, I was able to make it work by downloading the XCFramework , dragging it into the project’s framework folder, and then linking it to the targets. There’s no real utility in wrapping it in a swift package just for use in a local project. Swift Package Manager doesn’t do anything special or magical - it’s just a way of easily distributing packages to consumers. But if you’re not creating a package for distribution, there’s nothing gained by jumping through hoops to put a framework file in a swift package - you’re just adding extra layers or code.

[nharbo]

@badepaz my notification package contains many other things, and we use local swift packages to bundle code. It's not necessary for our full project to know about the AzureNotifications SDK - only the notification package knows. And then the rest of the app uses it through an interface. But yes, I guess there's many ways of handling this :) I just posted my solution in case anyone else needed it wrapped in a swift package. Never said it was necessary ;-)