[feat] Unify macOS and iOS dev & build

[DeTeam]

Describe the problem

My cross-platform app is growing and now an App Extension as part of the bundle (Network Extension). I would like that extension to potentially share some of the code with the main UI as well as share common native Swift code between ios and mac.

It was fairly straightforward to setup an additional target for ios since it's possible to overwrite xcodegen project.yml, which would make tauri dev and tauri build work smoothly. However it was not an option on mac. It gets even trickier, since for NE to be installable on mac, both app extension and the main bundle must be properly signed and have at least a dev provisioning profile (often times managed automatically by xcode).

Describe the solution you'd like

I feel like being able to customize and play around with the xcode project for mac, the same way it is for ios, would be nice if all of the important cli commands support it.

Alternatives considered

I guess an alternative for me would be having own version of tauri dev for this specific case + shell scripts for resining the bundle when doing tauri build 🤔 .

Having a flag to keep dev (!custom-protocol) feature on would also make things easier, since then it's just running tauri build --debug --dev + bundling with xcodegen & xcodebuild.

Additional context

No response

[FabianLars]

I feel like being able to customize and play around with the xcode project for mac, the same way it is for ios, would be nice if all of the important cli commands support it.

I get the sentiment, the issue is just that tauri doesn't use xcode or an xcode project for macos builds so this would be a pretty hefty change.

It gets even trickier, since for NE to be installable on mac, both app extension and the main bundle must be properly signed and have at least a dev provisioning profile (often times managed automatically by xcode).

At least for tauri build this shouldn't be much of an issue i hope. Both parts, signing and the profile, are supposed to be supported, with the latter seemingly being included like a simple file https://v2.tauri.app/distribute/macos-application-bundle/#adding-custom-files

Do you have to go through that struggle to make tauri dev work as well? That would be tricky because we used to have that work more closely like an app bundle in the past (but still not an xcode project) and it caused more problems than it was worth.

[DeTeam]

I get the sentiment, the issue is just that tauri doesn't use xcode or an xcode project for macos builds so this would be a pretty hefty change.

Absolutely. I just found it quite tricky to use more of mac native APIs, especially ones requiring app extensions. tauri build and custom files are fine, however do require developing and signing my app extension separately.

My main challenges at the moment are around:

1. Making the app I tauri build actually call the dev server
2. Share the code between ios and macos, allow for various targets (app extensions)

I'm working around first first one by setting frontendDist equal to devServer. And the second by having and xcodegen project for mac and having custom commands for macos build and dev.

I think a simple thing that'd help me is to allow cfg!(dev) to be true not only from a hard-coded feature (false for build, true for dev), but also from a flag, perhaps.

[FabianLars]

signing my app extension separately.

developing yes, but signing should be done by tauri at least once #14319 lands.

I'm working around first first one by setting frontendDist equal to devServer.

Sounds like the correct approach i'd say. If you need another frontendDist you can instead configure https://v2.tauri.app/security/capabilities/#remote-api-access which should give you the same result (minus the navigation to it).

And the second by having and xcodegen project for mac and having custom commands for macos build and dev.

Sounds reasonable as well. A bit offtopic but did you also check out https://github.com/Brendonovich/swift-rs ?

I think a simple thing that'd help me is to allow cfg!(dev) to be true not only from a hard-coded feature (false for build, true for dev), but also from a flag, perhaps.

hmm, i don't think this will be something we add built-in but you can always use a normal rust feature for that and supply it with --features my-dev-feat and check for it via cfg!(feature = "my-dev-feat") (you can also create an alias so you get a short cfg!()

tauri/crates/tauri/build.rs

Lines 228 to 257 in 3397fd9

	fn has_feature(feature: &str) -> bool {
	CHECKED_FEATURES
	.get_or_init(Default::default)
	.lock()
	.unwrap()
	.push(feature.to_string());
	// when a feature is enabled, Cargo sets the `CARGO_FEATURE_<name>` env var to 1
	// <https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-build-scripts>
	std::env::var(format!("CARGO_FEATURE_{}", AsShoutySnakeCase(feature)))
	.map(|x| x == "1")
	.unwrap_or(false)
	}
	// creates a cfg alias if `has_feature` is true.
	// `alias` must be a snake case string.
	fn alias(alias: &str, has_feature: bool) {
	println!("cargo:rustc-check-cfg=cfg({alias})");
	if has_feature {
	println!("cargo:rustc-cfg={alias}");
	}
	}
	fn main() {
	let custom_protocol = has_feature("custom-protocol");
	let dev = !custom_protocol;
	alias("custom_protocol", custom_protocol);
	alias("dev", dev);
	println!("cargo:dev={dev}");

)

[DeTeam]

Thanks @FabianLars yeah, all sounds reasonable.

https://github.com/Brendonovich/swift-rs — using it too.. I do want to use some shared rust libs inside of some of the swift wrappers and there's a bunch of back and forth, so swift-rs is quite useful. On a side-note I noticed that tauri in a few places accepts c strings back instead of SRStrings.. I tried to poke at it and faced some weird panics, so ended up using c strings too.

With the cfg!(dev) I'm just a bit worried about facing some issues with framework code assuming that we indeed should be in dev mode and not build, but so far so good 😅. Having a separate feature for this mode is an option, sure!

developing yes, but signing should be done by tauri at least once #14319 lands.

I'll keep an eye on it, but it seems that sining can be just done by xcodebuild/xcodegen. The downside here is, that by taking over what is effectively yarn bundle, I'd have to implement all things like moving icons around, additional files, sidecars, etc.

[DeTeam]

Ah, another thing that'd be cool to have: allow things like Channel/Invoke in the Swift side of the tauri sdk to be used outside of iOS (they depend on UIKit atm, if I remember correctly).