Hide Published Child App?

Is there a code snipped to get a published child app to be hidden from the mobile GUI? I realize the child can just be saved and not published, but with the save/publish muscle memory this is a pain whenever updating the child.

Once you publish the child, the only way to update it after that is to publish. If you never publish the child, you don’t ever have to publish it. Once you publish it, it does show up in Marketplace / My Apps, but it’s not useful there – it can only be accessed from the parent.

The only way to undo publishing is to completely remove the parent-child, and start over.

Thanks Bruce. You would think that there would be a some metatag that could be added to a child to hide it from the mobile GUI.

1 Like

It’s harmless. The main risk is not realizing that you’ve published the child. I had one Rule Machine user who had published but was unaware of that. He didn’t get any updates for a month. He could install the update in his IDE, but without publishing it, there it sat.

Now, the documentation for Rule Machine just says, Save and Publish for Me, for the child app. Safer from a user perspective.

I recently suggested adding a metadata field for child apps to @jody.albritton and @slagle and they both seemed to be on board.

On board, yes. Getting that change is still going to take some time.

1 Like

Yes, we know the prospects. Lots of good ideas abound.

Here’s one: Replace Routines with Rules.


What would that look like to the user? Are routines not rules of a sort?

Yes, totally wimpy and inadequate ones. Had that not been the case, there would have been no need for Rule Machine. An automation system needs a complete rule engine. Routines fall miles short.

Like Routines do from a dashboard view. But with Rules instead of Routines, as in what Rule Machine offers now (or an improvement on it). Create new Routine is like Create new Rule, etc.

Rule Machine is about 2000 lines of code, that ST already own rights to. You could take that as a starting point and turn it into a hardened product. The user feedback is that RM is what ST should have had from the beginning. The functionality works, it solves most automations (including everything that Smart Lighting does). The UI could be argued about forever. The virtue of RM is that it had a single impassioned author with an attitude about what it should do and how it should look. It works. Routines often don’t, and leave a huge gap in what people actually need from ST.