Yeah, this one caught me off guard. We just purchased a MacBook Air in the last month and if we bought the same one now, we would save $200. Apple support would not price match/correct that, so we will be returning it and purchasing anew.
I'd love to know more on the business-front for deals like this. Is that a yearly cost? What's the typical expectation for support for something like this?
This definitely isn't my realm of experience at all, so I don't even know if this is a big deal or not. The fact they noted the "bragging rights" makes this feel like a low cost.
Thank you for providing pre-set examples on your site. That's one of the major barriers on these types of tools to "test" especially when you're not sure where/how/if the images are public.
Not sure how I feel about this. Figma is great and all their feature releases have been impressive, but I feel it was due to competition and worry about similar products coming in from big corporations (like Adobe XD). I feel this competition really push Figma hard.
Now being part of the same owner, just makes it feel like any aggressive progress will just stall out.
We've been struggling with this GitLab storage change, even consulting with GitLab reps on strategy logic between namespace versus repositories. It's still very confusing, especially if you were using their other offerings like CI/CD build systems and associated build artifacts storage.
The artifacts storage is that one that's just tough to figure out when dealing with large builds. We have already offloaded all our CI/CD to our own hosted GitLab runners, but apparently storing the artifacts afterwards (which by default GitLab always stores the most recent builds) MUST use their storage, we can't offload it to our own servers.
What's the error / job logs you are seeing with having the project settings disabled for keeping the latest artifacts? The async operation to delete artifacts can take a while. Suggest to continue on the GitLab community forum: https://forum.gitlab.com/ where more folks can help. If you continue seeing the problem, also suggest to create an issue as a bug report. Thanks! https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_t...
I might be alone, but I'm really struggling with this line of fixes from Gitlab.
To be clear - I'm all for Gitlab charging, I think that's fair and reasonable.
However, if they're gonna charge for artifact storage, they need to provide first-class tooling to manage the storage.
My experience is almost exactly the same as the OP's. Huge artefact storage from builds, the scripts to clean up don't work.
> The async operation to delete artifacts can take a while.
How do I tell if something has succeeded or failed then? Last time I ran the scripts, no errors were mentioned, but nothing was tidied up.
Cleaning this stuff up shouldn't be via hacky scripts or community projects. It should be a mandatory requirement for managing an aspect of my account that's about to become very very expensive.
Oh it feels great to learn I'm not alone in this problem. I completely agree with everything noted here.
The current interface provided for removing the artifacts on GitLab just does not work. There is no feedback; no confirmation. We just uncheck a box and just cross our fingers since there is no other step noted.
Even with the new guidance provided, it's still additional jumps through other codebases just to see if it works. I'm now worried that if I go through this new process, I'll end up right back at the same issue.
Just in case anyone from Gitlab is monitoring this thread, there remain issues[0][1][2] in the artifacts listed both in the UI, and returned from the API, resulting in artifacts unable to be deleted.
It's clear that the gitlab dev team are aware of these issues, but given they've been open for years, I'm not convinced they'll be resolved before the pricing changes kick in, in a little over a months time.
If not addressed, according to the FAQ, teams builds will start failing, as they'll be unable to publish artifacts, and unable to manage the artifacts, essentially leaving them blocked.
We recently used Turborepo -- https://turborepo.org/ -- for a project that started as a two Electron-based builds that quickly escalated to a three Electron-based build. Once we had it set up for the two, it was quite easy to add one more. Our shared components were in a central package while custom ones existed in their respective app directories.
The nice thing with this type of separation for us is being able to target CI/CD scripts to specific apps. Previously we were using targeted dev script logic to initiate the different app builds which just wasn't maintainable. This new approach this time around made for Electron deployments to be super simple, consistent, and repeatable.
All this was done by two team members on dev side.
Would you be willing to share how that compares to your iOS side? I see you have Apple Watch support which I assume is easier to monetize for your space.
Good question! Per user we make about 1/2 as much on Android compared to iOS, but we're currently getting 2x traffic on Android so it's pretty much a 50/50 split ~$20k each.
Super interesting, do you think the traffic difference is anything to do with your app and marketing, or do you think it's to do with the size of the android market compared to iOS?
95% of our traffic is organic so it's not anything to do with marketing. I think it's just that we're ranked much higher in the Play Store than we are in the App Store atm. The iOS App Store is much more competitive (in our niche) and we haven't yet cracked the ranking algorithm :D.
I'm excited overall about these 'leaks' and details surfacing from Apple and Meta. I'm optimistic the AR side will win (versus VR only), but overall, by being shepherded by these big orgs, I expect hardware costs to reduce dramatically for end users. Lower costs will pull in more users and allow us to really design experiences for a wider AR audience.
