Okay, I wanted to take my time in responding as I answered some of my own questions. Also, my app has made it to the the app store (here) so no big issues.
Most of the time changes will only be in the www folder.
This has helped a lot already. Thanks for confirming.
However some project changes may affect the Xcode project too, such as changing project settings . . . a diff tool can easily show the difference
I threw the exports in a repo, as I should probably do that anyway, and used git to compare. Indeed things like changing project settings or adding new plugins that require changes to the browser APIs (like touch or audio) will cause other changes. There are some differences in some hashed looking lines, which I threw in ChatGPT asking what it was, and they were identifying build files. So I'm hoping the hash reference changes but the contents stay the same, therefore don't need any update.
So far, I've replaced only the WWW directory multiple times after making changes to mostly events and have not come across any issue from that process.
Remote Preview is designed to let you quickly test on mobile without needing to export every time. Is there a reason you're not previewing with that for faster iterations?
Honestly I forgot about Remote Preview completely when I posted as I was trying to test out the workflow and troubleshoot any Xcode issues up front. So I apologize for making it sound like the normal workflow.
Although there still are reasons for needing to export:
- Fullscreen: the remote preview has the navigation bars from the browser. I was trying to decide how I want to use that extra space, such as scale outer and what will actually show, so need to see how it will actually show native in device
- Device Emulator: Checking it across different devices that a person doesn't own
- Troubleshooting: Probably more of an Xcode area, but troubleshooting any issues with the project in Xcode
- Apple Review: Upon Apple rejecting your submission, you will need to make changes and re-export
- Updates: releasing new versions
Since re-exports should be expected, I'm hoping to figure out a workflow to minimize the pain points. Personally, I'd prefer to use the same Xcode project file, even if it is just so that I can keep the project open when merging a new export and don't get confused if ever trying to "open recent" or something.
AFIAK the process for exporting to iOS hasn't changed substantially over the past few years, so the existing documentation should still apply. If anything is out of date then let us know.
Now that I have worked through it and resolved everything, the Docs still seem relevant.
When I made the comment I was looking mostly at this tutorial which is 5 years old and I ran into an issue when I got to Previewing in Xcode, which is about a tenth of the way down the page. Then I looked at the comments to see if anyone else experienced the same thing but saw others asking for an update.
The issue I came across was related to pods. For reasons I can't state, I cannot install cocoapods. Therefore, my workaround was to remove a couple lines of code:
So far so good, though I do want to look into that more to know what I am removing.
As far as documentation and tutorials, are there any gaps you see?
I feel like I've read through most of your blog posts related to this topic, such as how to plan for mobile games with touch controls etc. - so know you have a lot covered.
I tried to take notes on the steps along the way. Not sure if it is worth the effort to try and make a tutorial - a lot to cover and a lot already covered.
But maybe I could add value diving into a bit more details on Xcode or the Apple Developer portal side of things. Though I understand it doesn't make sense for Construct to document tools or processes you don't have control over, these are pain points your users most likely come across. If they can't turn to Construct site (forums, tutorials, docs) and need to turn to Apple Docs, that can be rough finding what you are looking for.