iPhone apps have not been able to build to a physical phone for about 2 weeks now. Any updates? @wade
A number of us have been having this issue, I wouldn’t be surprised if it was platform wide. The common response is that “engineering are looking into it”. As the issue is easily replicated, i would say that the cause has been identified but all resources are working on the flutter platform update and therefore the lack of support is the first step in deprecating the current platform. Happy to be proven wrong @wade.
Yes, this is system wide. We are working on solving it. I don’t have the in depth nitty gritty details of the issue but I know we’re indeed working on solving the error with our Builder for device builds.
I don’t have an update yet to share but as I receive more information, I will share it out.
We’re a small team working very hard and will get this cleared up so you can continue to test and deploy your device apps. Thanks for your patience while we work through this. More info will come.
@chris We have solved the issue internally and Device Builds are succeeding again. Thanks for your patience while we worked through this difficult issue. You should be good to go now.
I forwarded fail builds I’ve been encountering. Looks like iOS is experiencing this issue again.
Want to share a Build ID with me here and I’ll take a look?
Any update on this issue?
The error in the code refers to the API call GET msassageHasAvailableLurchPhpOperation and the (!) and I’m trying to figure out why it’s trying to unwrap the Type INT here. I don’t have an answer yet as to why this is occurring. Still researching and testing.
Yeahhhh, this has been a weird place for me. Whatever my server returns the client, (iOS) gets hung up on the same (previous) return value. It’s the only API to have this sort of issue. BIZARRE!!!
I am curious about the logic. Like you’ve got an Int Page Variable here and then there’s some logic if/else before setting values from an ResponseObject, etc etc. It looks correct theoretically but also it’s complex so I’m looking to figure out the why so we can adjust something to get the effect you want here.
Well, I’ll provide whatever I can because this is a major roadmap set back. Basically, the API hasAvailableLurch makes a call to see if there are available massage therapists (lurches) before a customer can request a massage. The endpoint is contractually obligated via swagger to return a string “true” or “false”. But out of no where, when the API would change return values, the app was stuck on “true” when the server would clearly be returning “false”.
So what you see now, is me mucking around and changing the return type to a 1 or 0, just experimenting to see if it would consistently observe the correct value. And I’m assigning it to a variable before evaluating the returned values. But initially, I was just evaluating the API response body values, without putting it in a variable.
Basically, I was just trying to stuff in order to fix something that had been working this whole time and stopped working out of nowhere.
I like the BOOL idea and it would probably change what’s happening since this seems like the issue is from us trying to unwrap a non-optional Int. But instead of using Strings like “true” and “false”, send just a bool without the quotes of true and false. Then your page variable can be a BOOL and you can set it per the ResponseObject’s value.
This is just a thought for something to change and see if we get a different result here.
WOW! Ok great! Glad that worked. Thanks for reaching out. That’s why we have this community. Sometimes just a suggestion change in tactic can overcome an obstacle. Glad you’re moving forward again!
I reported a build failure with Android. The issue was with the same API call. I had to fully delete the API to get it to build. I thought this was an extreme measure to take and never had to do this before after I update the Swagger API.
Yea that sounds odd but perhaps something got mixed in there. A full API flush is a step that can work but you’re right, it can be extreme in situations.