-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Attempting to run the macOS target fails with errors #156
Comments
So, I spent a good couple of hours on getting the macOS target to build. My intention was to create a framework for the shared code (cp. #155), and to check that the framework properly integrates with both the iOS as well as the macOS project, I need them both to at least successfully build. The more I went after the build errors and attempted to cut loose bits of code here and there, I was wondering whether this is worth the effort. Sure, a macOS application would be awesome to have as well, but I don't see an actual need for it. If I was editing OSM data on my laptop, I'd fire up JOSM. That editor is way more advanced than what I need, and is still being maintained and extended. To cut to the point, I suggest we remove the macOS project from the repository and concentrate our energy on bringing the best OSM editing experience to iOS. This might sound a bit drastic, but I just wanted to put it out there to discuss. @bryceco, what's your take on this? What are your plans for the macOS application? |
I agree. |
I agree there is no great need for a Mac editor. In addition Apple indicated that next year it will be providing support to simplify porting iOS apps to Mac (see this year's WWDC), and when that support ships it should be pretty easy to tweak the iOS code for desktop. However, until Apple does that and a desktop editor is a reality I don't see any reason to delete the Mac port. It really has no impact on day to day development for iOS, and if Apple changes course it may be useful to someone somewhere. |
Thanks for your input, guys! We might not need to implement new features on both platforms, that's correct. And we might even be able to make the project build again (which, as I said, already took me a couple of hours, to no avail 🤷♂️). With each API change in the Shared code that is not backwards-compatible, we need to always maintain the macOS app to some extent, even if it's just making sure it at least builds. Let's assume we keep the code for the macOS target in this repository. What do you guys think should be done about the failing build of the target? |
The Mac port hasn’t compiled in at least 5 years. If someone really wants it to build then the onus on fixing it and maintaining it will fall on them, though I’m happy to help out and actually spent quite a bit of time trying to make it compile last month. |
I've pushed the branch with my attempt to get the target to build. Take a look if you have the time, maybe it helps. How about we remove the dependency on As for the target itself, I guess the question on whether to hide the code with |
MapView is the centerpiece of the shared code, and is derived from UIView/NSView. It already incorporates a lot of functionality that rightfully belongs in a view controller instead of a view. Can you explain the approach you envision to remove the dependency on UIKit while still keeping that code shared? |
Thanks for your insights! Yes, let me elaborate a bit. If we wanted to represent a color value, we have different options. Using "bridging macros" as in
|
For what it’s worth, this is something that a continuous integration tool such as Travis, Bitrise, or CircleCI can prevent. The repository can be set up so that no pull request can be merged until both the iOS and macOS builds compile without errors. Of course, that would require addressing this issue first. 😉 Once the macOS build compiles in the first place, keeping it green would involve a smaller amount of work in each PR that touches shared headers. The Mapbox GL Native project, for instance, has iOS and macOS builds even though most of the developers only routinely develop for iOS. This primarily works because there’s a strong separation between cross-platform files (that mostly only use Foundation types) and platform-specific files. In the few cases where cross-platform files use UIKit/AppKit types, we use conditional compilation macros or platform-specific headers. For UIColor/NSColor, we use a “bridging macro”, because most of the usage in that project involves initializers and properties that are common to both platforms. But the symbolic approach in #156 (comment) could also work if the number of colors is fairly limited. |
Thanks for your input, @1ec5! That sounds like you have experience doing this. Do you think it's feasible to have a "Shared" framework (cp. #155) that solely depends on Foundation, and have the platform-specific code in the dedicated targets?
When running unit tests locally, does their scheme also run the test for the respectively other target? (For example, when running the tests while developing the iOS app, are the tests for the macOS target also run?) |
Without having looked closely at what this *OS framework would contain, I’d say it’s definitely feasible. It’s a tradeoff: it means one more framework to load, which may or may not be desirable; on the other hand, it means you don’t have to remember to add a file to both iOS and macOS targets. Solely depending on Foundation can be merely a rule of thumb; if convenience dictates that UIColor/NSColor be used in an otherwise largely Foundation-only class, a modicum of conditional compilation can keep the code in one place.
No, only the iOS tests are run, because a single scheme can only target a single device at a time. We’re relying on the CI bot and contributing documentation to head-off problems before merging. I should note that gl-native isn’t an ideal example of sharing code across Apple platforms: the iOS and macOS targets live in separate workspaces for historical reasons (mapbox/mapbox-gl-native#5942). A more conventional example would be MapboxDirections.swift, which has a target and scheme for each of the four Apple platforms in the same Xcode project. (Sorry that I’m just talking instead of offering code here. My to-do list is running long!) |
Just a note that using Catalyst its now possible to run the iOS version on Mac. |
Now that with Catalyst on Big Sur native feeling UIKit apps on the Mac are possible (and the Mac version of Go Map!! isn't currently a thing anyway), i'd suggest removing the Mac target and unifying shared and iOS code and removing the |
I agree its probably okay to delete the Mac port and stick with Catalyst. A couple comments:
|
Does that mean you'll accept pull requests that go ahead with this? |
After the next release (2.x) we'll bump the minimum iOS version to 10 or 12. That will open up the ability to add many Catalyst-specific improvements that are otherwise held back by iOS 9. Once the Catalyst version is looking fairly reasonable we can delete Mac. |
I've been improving support for Mac Catalyst the last week and it's looking pretty good (though still quite a few small things to fix). Feedback welcome! Right-click (with a mouse) or Control-click (without) replaces the + button for drawing. |
Mac Catalyst support is now stable |
But that is for the next release, right? Or how would I download it on macOS? I guess it would be AppStore => Search "gomap" => Results "iPhone & iPad Apps" => Download? |
Yes, next release. I assume that Catalyst apps are downloaded exactly the same as regular Mac apps. |
Steps to reproduce
OpenStreetMap.xcodeproj
CMD
+R
Expected behaviour
The project builds and the app is launched for debugging.
Observed behaviour
The app fails to build with 11 errors.
The text was updated successfully, but these errors were encountered: