Hi there,
I'm facing this issue. If it helps, this is how I'm getting around the issue:
brew install ideviceinstaller
Then:
plug in phone
make an archive with XCode
ideviceinstaller -i MY_ARCHIVE.xcarchive/Products/Applications/APPNAME.app
This will install the app directly to your phone in about 2 seconds. To reinstall, make another archive and rerun the ideviceinstaller command above.
You might need to also do install this:
brew install libimobiledevice
You can read more about 'ideviceinstaller' here:
https://github.com/libimobiledevice/ideviceinstaller
Best,
Lee
larromba
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Last seen
User for
Post
Replies
Boosts
Views
Activity
@henrik273 thanks for confirming this is a SwiftUI bug - it's been driving me nuts for days.
It seems the button uses the initial disabled state upon tapping it, regardless of its current disabled state.
This is the only reliable work-around I've found:
set the initial state to be .disabled(isDisabled) where isDisabled is false.
set the text field to have some default text that the user must delete.
when the user deletes all the text, isDisabled becomes true.
The closure only gets called if the initial state is .disabled(false) rather than .disabled(true). Also, the alert must appear with .disabled(false) before you update to .disabled(true).
Another hack could be to use DispatchQueue to update .disabled(true) ~0.6 seconds later (so after the alert appears), but I wouldn't recommend this as it's not reliable.
I hope this helps whilst the bug is fixed.