Not sure digging up your Slack, Google, Apple API keys is faster...and probably also more of a hassle for compliance than just using Slack and Email which are already there.
That is definitely one way to solve this specific problem, you're right!
Although the future of Statused holds more than just forwarding emails to Slack. I intend to add support to other "channels", such as Teams, Discord and Telegram, as well as other types of integrations such as incoming webhooks, so a status update could directly trigger a custom action in your CI/CD pipeline, for example "detect the app has finished processing, then submit it for review".
On top of that, I don't think you get those emails for every Google Play changes that are made to your release, so not sure if that would work. Again, this might work, but I'm really not sure.
You have a point with those concerns about sharing API keys. But this has become pretty standard and devs share those keys with a bunch of services already, such as as with CI systems, app store user review services, sometimes ASO monitoring tools even.
No, it's a dedicated email you can set up for any channel, it's usually something like "channelname-somerandomcharacters@example.slack.com". On the GMail side you'd just set it up to only forward things that have the subject line you want like "Rejected" etc.
Seems oddly over-specific. Don't they send mails when it's approved/rejected? So is this basically a mail-filter connecting to slack? Just that it's using an API-key. How save is this API? How much can one screw up things or steal data with that key? And it seems rather expensive for such a one-trick task.
Maybe add some more signals to get a real value for the customer, like a real mail-filter, RSS and other newsfeeds (which is popular here) or some dozen more APIs.
I agree with your points. The point of gathering the API key is to actually be able to provide a lot more information in the future, such as some light data science (analytics) into your releases, and maybe expand to other areas (e.g. taking actions from the Slack messages themselves).
What do you mean with "like a real mail-filter"?
The RSS feature is kinda on the roadmap but I haven't gotten any feedback about users wanting that type of integration. Incoming webhooks is higher up in the list, so users can trigger internal CI actions upon receiving requests to such webhooks.
Any other type of APIs you'd like to see this tool covering? :)
> What do you mean with "like a real mail-filter"?
I mean receive mails from a mail-server (pop3, IMAP, Gmail, exchange, etc.), filter according to user-specific criteria and output on slack. This might even give some additional value by having maintained filters, if you can get your hand on enough for your customer's relevant mails. And it would give opportunity to shrink the privacy-problem, as people could use dedicated mailboxes for such mails.
And you could even reuse the filters+interface for all other sources too. Like maybe, they only want to see certain releases, or for a specific app.
> Any other type of APIs you'd like to see this tool covering? :)
That's a problematic question. There are too many apps and APIs. You could focus on the common tools, like issue-trackers (Jira, etc.), error-trackers (sentry, etc.), maybe Slack itself? But instead of just adding APIs, the actual value for your customers might be to add unique use cases which pushes your tool above the existing workflows. Adding statistic and appeal to rejections seems worthful on surface. But you should be aware that you are competing with others tools, like Zappier or a simple mail-clients, and you likely have not enough manpower to beat them on their ground. So you may better focus on quality and additional value for your customers, and communicate this very very well.
I built a similar open-source thing a few months ago which pulls in a lot more information and you can even control things on the store through Slack commands: https://appstoreslackbot.com
Currently, it only works for iOS and is pull-based.
This is amazing!! Congrats on putting together all that functionality!
How many users are using that service? How come you decided to make it 100% free?
Your website is beautiful btw! I thought about building my tool as a Slack bot but thought that then it would be too limited to only Slack. I intend to add other types of workflows in the future, such as webhooks (to trigger special workflows in your CI) and a RSS feed :)
I'd love to connect with you if you wanna work together on something! t.me/rogerluan
We have around 10 users right now since we haven't marketed it too much. But would love to spread the word around.
We built this in about a week as it mostly piggybacks on a critical piece of infrastructure behind https://www.tramline.app, and hence kind of runs by itself.
So we didn't really care for adding pricing to it. Tramline is what we _really_ build :)
The service itself just currently happens to respond primarily as a Slackbot, but that's just an implementation detail and can be tweaked.
Would love to connect, let me ping you on telegram!
The cool thing is that I don't intend to take it down now that I built a SaaS around it. I'll keep both open source and SaaS versions of it live, and try to upsell the service to those who don't feel like self-hosting it. Plus, the SaaS version comes with features not available in the open source version (such as support to Android) :)
That's great! We may actually use your hosted service since we haven't had the resources available to setup the self hosted version.
Edit: Some quick feedback. Your pricing uses the word "workflow" but what that means isn't described anywhere on the site or FAQ. I assume it's used once you create an account but it's not clear what it means before signup.
Ooh, that's super valuable feedback, thank you so much!
I'll fix that right away.
PS: Lemme know if you need any guidance setting things up or have any further questions! There's the official support email but also white-glove treatment at t.me/rogerluan ;)
You'll notice that the subscription is based on workflows. A workflow is a connection between a source (e.g., your iOS app) and a destination (e.g., a Slack channel). You can set up as many workflows as you'd like, which is a great way to separate different types of notifications. For instance, #ios-deploys-prod receives updates about your production app, #ios-deploys-staging receives updates about your staging builds, and #android-deploys-beta receives updates about the Beta track of your Android builds. Each of these is a separate workflow.
For Play Store, it specifically mentions that it only does:
> When you submit a new build to one of the tracks (internal, alpha, beta, or production), they go through different statuses, e.g. “In Progress”, “Completed”, “Halted”, etc. Each of these will send a new notification to your team.
It's for Android/iOS apps, thus, app approval/rejection from e.g. Apple, but also applies to other app statuses too :)
Key features:
- Real-time Slack notifications for iOS and Android app review statuses.
- Instant alerts for TestFlight releases for your internal team and external testers.
- Updates on app processing changes, all in one place.
- there's more, but those are the main features
Happy to answer any other questions you might have! I wonder if the landing page isn't clear enough; is there anything you'd improve on it?
It is a nice idea. I worked at a place that had an app back in 2012 and something like this (had we used Slack) would have been very useful. I haven't worked with apps for a long time but I can see it being useful.
Thanks! If you do go back to working with mobile apps in the future, don't forget to check it out :) even if the project doesn't get any customers, I don't intend to shut it down, because it's super useful to me personally, so it should be up and running for years to come ;) — assuming Google/Apple doesn't kill or sherlock it lol
Thank you! I'm really excited for this!!
Gonna continue building things that solve pain points I have in my daily routine, which might be useful to others too lol
So, I put together a hacked version of this 3+ years ago (Aug 2020) in a few days and was up and running. We used this at my previous company for 3 years, until I decided to transform it into a micro SaaS.
The SaaS took 270 hours so far (so if I had done this in a typical 9-5 schedule, that would've taken me ~6-7 weeks). Sounds like too long, and it is, but considering I knew nothing about BE, FE, db, infrastructure, etc., and that I built it from scratch, completely ditching the previous version I had, it was quite a fun journey!
Statused is crafted for app developers, project managers, and QA teams who crave efficiency and a central point of communication for their app's release cycle. The larger the team looking to streamline its process, the better.
Using the words of one of the customers I have: "it shifts the paradigm from us needing to pull information to getting it pushed to us! Really helpful!"
It frees up time of mobile developers' and democratizes the access to the information across different departments :)
Lemme know if there are other questions I can help answering! Happy to explain anything in further details
Not sure digging up your Slack, Google, Apple API keys is faster...and probably also more of a hassle for compliance than just using Slack and Email which are already there.