Paw: The ultimate REST client for Mac(luckymarmot.com)
luckymarmot.com
Paw: The ultimate REST client for Mac
https://luckymarmot.com/paw
117 comments
After trying to figure out why Postman was doing a double GET this morning on a coworker's computer, I finally told him to just install httpie. Took a little while but it's much easier to be explicit about a request. Bash command history does a lot of what these GUIs do.
You probably wanna tell the Postman team[0] about this. They are a bunch of helpful folks who are working very hard on building the product. They'll be glad to see the bug report.
Full disclosure: I interned with Postman for a short duration last year.
[0] - https://twitter.com/postmanclient
Full disclosure: I interned with Postman for a short duration last year.
[0] - https://twitter.com/postmanclient
You can ping me at @postmanclient or email me at abhinav[at]getpostman.com. Would help in figuring this out.
I find the Collections feature in Postman to be really helpful. Is there a similar feature in Httpie? I couldn't see anything on the github README.
HTTPie is a CLI client, and I don't think it would make sense for it to save the requests you make (as opposed to a GUI). Though, it has a nice persistence feature with sessions (https://github.com/jakubroztocil/httpie#sessions).
It's the nice thing with GUIs (Paw, Postman...)! Paw saves all your work in ".paw" documents that you can share with your team on Dropbox or Git. You can have many documents, and organize your API calls.
Disclaimer: I'm the founder of Paw.
It's the nice thing with GUIs (Paw, Postman...)! Paw saves all your work in ".paw" documents that you can share with your team on Dropbox or Git. You can have many documents, and organize your API calls.
Disclaimer: I'm the founder of Paw.
Hello, Paw looks nice.
Can it compare a response to a previously saved response? That would be handy for looking for regressions when refactoring the code behind an API.
Can it compare a response to a previously saved response? That would be handy for looking for regressions when refactoring the code behind an API.
Yeah, diffs on JSON responses are something we are thinking about! But tests/assertions are what would make your APIs regression proof.
I didn't know this existed; my curl-fu is weak--this will come in extremely handy. Combined w/ jq this is a new tool in my daily workflow. Thanks!
It can generate basic auth headers, handle OAuth workflows, store variables in different "environment" containers per project, export the request in any of a variety of formats (jQuery, curl, etc:) - it's a brilliant piece of software, and I use it almost every day.
Can you automate it? i.e. is it useful for non-interactive work like automatic testing?
Postman founder here. Postman let's you run tests outside of Postman through the newman tool (free) [1]. Just take collections outside Postman and run them anywhere you want. Collections can have Javascript scripts embedded inside them for request chaining (transferring data from one request to another) or just writing integration tests. Tons of possibilities and we have some great new stuff coming up around this.
[1]: http://www.getpostman.com/docs/newman_intro
[1]: http://www.getpostman.com/docs/newman_intro
Can you tell what is current status of extension - is it still supported or packaged app is the way to go nowadays?
Are you planning to go more native with something like Atom's Electron platform?
Are you planning to go more native with something like Atom's Electron platform?
We just push bug fixes now for the legacy app. The roadmap of legacy apps from Google is still not clear. I would strongly suggest the packaged app way for multiple reasons (folders, in-built documentation, syncing, real-time sharing, tests, request capture).
And yes, native apps are coming soon! Atom's Electron is a strong contender. We are exploring all possible options. :)
And yes, native apps are coming soon! Atom's Electron is a strong contender. We are exploring all possible options. :)
There are many better ways to do automatic testing. I've never used Paw for that, and I don't think it competes with e.g. postman on that front, if that's what you're asking.
However, for manual testing / having it write curl commands for you / making JSON really easy to work with by hand, it's fantastic, and I've converted a few people at work to it. Developer is also very responsive and nice to work with on Twitter.
Edit: you can also write extensions in JS for it. Not quite as accessible as e.g. Atom, but still decently hackable: https://luckymarmot.com/paw/extensions/
However, for manual testing / having it write curl commands for you / making JSON really easy to work with by hand, it's fantastic, and I've converted a few people at work to it. Developer is also very responsive and nice to work with on Twitter.
Edit: you can also write extensions in JS for it. Not quite as accessible as e.g. Atom, but still decently hackable: https://luckymarmot.com/paw/extensions/
Try Runscope (disc: founder) for that. Paw is my favorite desktop app but we are purpose built for automated testing and monitoring.
Thanks for the pointer, but that's not quite what I need. I don't need performance monitoring, I need regression testing.
https://www.runscope.com/docs/radar/assertions
You can do a whole slew of functional tests and as a bonus you can use those same tests for monitoring if you want.
You can do a whole slew of functional tests and as a bonus you can use those same tests for monitoring if you want.
Hi John :)
Go Twins!
Go Twins!
As the sibling comment says, there are probably better tools for automated testing. However, I haven't dove too deeply into this aspect of Paw, but I know that at the very least there is a "Run All" shortcut which runs all requests you have configured. The sidebar shows which requests succeeded and which failed. There may be some way to automate this. (It apparently supports extensions, if this functionality isn't built-in.)
We bought this app and I can safely say this is the best REST client I have ever seen or used.
The others out there (mostly the extensions for Chrome and Firefox) will do for most people but this app is just gorgeous and offers some nice features on top.
Some of the more mundane parts (JSON content in a post, basic headers) are handled in a couple clicks.
I love it.
The others out there (mostly the extensions for Chrome and Firefox) will do for most people but this app is just gorgeous and offers some nice features on top.
Some of the more mundane parts (JSON content in a post, basic headers) are handled in a couple clicks.
I love it.
Yep, loving it too.
Quite a few of the Windows users in my office are jealous of this particular application.
Quite a few of the Windows users in my office are jealous of this particular application.
How is it better from cURL, Python's liburl2 or libwww-perl?
It's not necessarily better, just a different interface that scales better to complex requests.
curl command lines can get huge and unwieldy. If a curl command has a huge amount of input, that gets unwieldy, too. Same thing with data input.
The fact that your requests persist and can be repeated and modified is useful. Better than looking up past commands in ~/.bash_history.
curl command lines can get huge and unwieldy. If a curl command has a huge amount of input, that gets unwieldy, too. Same thing with data input.
The fact that your requests persist and can be repeated and modified is useful. Better than looking up past commands in ~/.bash_history.
Ha, I feel the same way and started to make a little tool to help this, but most of the feedback I got was that it was pointless :( https://github.com/seiferteric/clamp
this is really cool! Great work.
Better than saving those requests in curlrc and recalling them with --config?
If you are quick with cURL maybe it's not--it's just a matter of preference.
I, on the other hand, can take quite a while to type out a cURL request with 4 custom headers and a long JSON body.
While I spent most of my day at the CLI I do step out for a few choice applications. Being able to quickly save and compile a bunch of requests to replay is also nice though I'm sure you could do that with cURL or similar tools.
It doesn't hurt that the app is particularly nice looking either :-)
I, on the other hand, can take quite a while to type out a cURL request with 4 custom headers and a long JSON body.
While I spent most of my day at the CLI I do step out for a few choice applications. Being able to quickly save and compile a bunch of requests to replay is also nice though I'm sure you could do that with cURL or similar tools.
It doesn't hurt that the app is particularly nice looking either :-)
Yeah, JSON on the command line can be a big PITA, especially when it comes to escaping. The old `curl -vvv -X POST --data @foo.json http://example.com` trick mostly works, but isn't the most elegant thing in the world.
This just might be, and it'll write the curl command for you too :)
This just might be, and it'll write the curl command for you too :)
Agreed. On a more positive note.. jq absolutely blows my mind for working in the other direction (reading)
jq: http://stedolan.github.io/jq/
jq: http://stedolan.github.io/jq/
jq is small peanuts compared to App::RecordStream.
https://metacpan.org/release/App-RecordStream
https://metacpan.org/pod/App::RecordStream::Manual::Story
https://metacpan.org/pod/App::RecordStream::Manual::Examples
https://metacpan.org/release/App-RecordStream
https://metacpan.org/pod/App::RecordStream::Manual::Story
https://metacpan.org/pod/App::RecordStream::Manual::Examples
I had been using Postman[1] for the last year or so and it's recently undergone a big update too which includes syncing. I've just tried Paw and like it more because:
- Native Mac app (it's prettier)
- I like the 3 pane window structure
- A lot of smaller UX things are nicer like duplicating, Postman annoyingly scrolls down, having to explicitly hit save, etc.
- Extensions
- Dynamic values
- Completions
Postman has the following which Paw lacks AFAIK:
- Collection automation and testing
- Chrome integration
- Dark UI theme
If I had use either of the 2 above I would not be able to switch over to Paw.
[1] https://www.getpostman.com/
- Native Mac app (it's prettier)
- I like the 3 pane window structure
- A lot of smaller UX things are nicer like duplicating, Postman annoyingly scrolls down, having to explicitly hit save, etc.
- Extensions
- Dynamic values
- Completions
Postman has the following which Paw lacks AFAIK:
- Collection automation and testing
- Chrome integration
- Dark UI theme
If I had use either of the 2 above I would not be able to switch over to Paw.
[1] https://www.getpostman.com/
On Macs I would consider the Chrome integration to be a down side as it seems to install itself as a separate application entirely, and thus in my app launcher (which annoys me, especially when I'm signed into Chrome + Canary and then it's showing up twice).
When you Command+Tab to it it raises the main Chrome window too which is annoying.
The positive side is the capturing of HTTP requests in Chrome.
The positive side is the capturing of HTTP requests in Chrome.
To expand on the point "Chrome integration", the most useful aspect of Postman is the "Postman Interceptor". You can clone any real in-browser request (primary page or ajax request) into Postman, ready to be replayed or modified then replayed. The amount of time saved when you're playing with ajax requests rather than a REST API is insane.
I switched from Postman to Paw primarily because the JSON pretty print functionality in postman couldn't handle very large JSON responses.
Paw is undoubtedly the best REST client, but that said I am slowly moving away from it as it's not cross platform .
I develop both on a Mac and Ubuntu system .
Slowly migrating to Postman https://www.getpostman.com/
Slowly migrating to Postman https://www.getpostman.com/
I've been using this for awhile, and I think it's quite pricey for what it does, as Postman is free and offers much of the same functionality. That said, this has a great UI and the grouping feature is awesome for managing multiple projects, and in general it works very well. One of my favorite features is the ability to "turn off" certain parameters but keep them in the request, so you can switch them on/off when you want to change maybe a field or two easily without making an entirely new request.
I really would like to see the ability to type JSON out in the request body manually instead of the somewhat-clunky input field deal.
I really would like to see the ability to type JSON out in the request body manually instead of the somewhat-clunky input field deal.
Re: JSON: You can: just use the text section. And you can go back and forth: you can type some text, then edit specific fields in the JSON window.
Text entry also autocompletes variables and dynamic value function names!
You can write JSON in the Text field, and it will be syntax colored if you add a "Content-Type: application/json" header. And you can switch back and forth between Text and JSON formats.
(I'm a Paw guy)
Somehow it does not understand what to do with my https://mydomain.io/blah url, it tries to fetch https://mydomain.io%0A/blah%0A
Postman has no problems with it though :)
Postman has no problems with it though :)
I think $30 for REST client is a bit too much since there are many free alternatives.
It's for professionals where $30 is both nothing and tax-deductible.
Agreed. If it saves you ~30 minutes of time, it's likely worth the $30 unless you're undercharging.
I work in a huge company and $30 is still considered something.
Not all huge companies have bosses that can see beyond their noses, and are capable of comparing the time an $30 app would save you to your hourly rate.
At the same time, if there was an app that cost half your yearly salary (e.g. $40,000) but automated all of your work and let them fire you, they'd jump all over it.
At the same time, if there was an app that cost half your yearly salary (e.g. $40,000) but automated all of your work and let them fire you, they'd jump all over it.
There is only really one free alternative with a comparable feature set - Postman. Postman is pretty good, but I would pay that and more for a decent (windows) alternative.
The most useful feature for me is 'dynamic variables'. I can use data value from a HTTP response as a variable in the request body for another HTTP request. It makes testing API endpoints that depend on each other a breeze.
I also like the 'environment variable' feature. I can easy test the API locally and on staging server just by changing setting different environments.
I also like the 'environment variable' feature. I can easy test the API locally and on staging server just by changing setting different environments.
Thanks! I'm the guy behind Paw, and I must say the Dynamic Values are our kind of secret sauce :) it's just one piece of the app, but it's what allows you to do pretty much whatever you want. Extensions are also nice, as they allow you to add new features yourself: https://luckymarmot.com/paw/extensions/
I'm actually surprised by how positive the responses are for this app.
First, I'm a bit turned off by it's use of the term REST. It's just an HTTP client. Gah, I give up.
I occasionally use postman, but more likely I'm writing a script that I'm going to integrate into my automated testing anyway. Or a simple one-off script with wget. I find that faster to use than a GUI but maybe I'm just getting too settled in my ways.
What was the use case that made you switch to something like this?
First, I'm a bit turned off by it's use of the term REST. It's just an HTTP client. Gah, I give up.
I occasionally use postman, but more likely I'm writing a script that I'm going to integrate into my automated testing anyway. Or a simple one-off script with wget. I find that faster to use than a GUI but maybe I'm just getting too settled in my ways.
What was the use case that made you switch to something like this?
Repeated manual testing of APIs at work across different environments. I used to just keep a scratch pad but with paw we were able to set it up and distribute a save file over Dropbox for the team to share. Variables for different environments were a nice touch, I guess you could bash script to your hearts content but this was a little less cumbersome.
Working on a project at work that's got about 50+ endpoints all saved in a single paw file. Paw makes it stupidly simple to go back to any of them. It also remembers headers and POST request bodies which saves a ton of time. Just found out in this thread that you can distribute paw files to the rest of your team to use. Should be onboarding new developers much easier.
Postman let's you do both. Use the GUI for explornig the API and use the CLI (newman[1]) for integrating with automated build systems. The idea is that you should not have to repeat yourself at any point in your workflow.
1: http://www.getpostman.com/docs/newman_intro
1: http://www.getpostman.com/docs/newman_intro
>First, I'm a bit turned off by it's use of the term REST. It's just an HTTP client.
And REST is just an HTTP based architecture.
And REST is just an HTTP based architecture.
REST, in the form coined by Roy Fielding, is actually almost the opposite of what "RESTful" means today, e.g.
> A REST API should not be dependent on any single communication protocol
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...
> A REST API should not be dependent on any single communication protocol
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...
> REST, in the form coined by Roy Fielding, is actually almost the opposite of what "RESTful" means today,
Not really the opposite. "RESTful", when it doesn't actually refer to Fielding's REST [0], generally doesn't mean anything, its just an empty buzzword being dropped into a product description that communicates no meaningful information at all. Even then, its seems to be intended to communicate "conforming to the REST architectural style", it just fails to do so because its done without any knowledge of the REST architectural style (and not even with an consistent wrong view such that the use of the term could be said to have a particular definition different from that that Fielding laid out for REST.)
[0] Though, to be fair, it often does, although sometimes to only some particular part of it (and not always the same part) as opposed to systems that lack the part being focused on. This use is somewhat consistent with Fielding's, though it would probably be better to focus on naming the particular element.
Not really the opposite. "RESTful", when it doesn't actually refer to Fielding's REST [0], generally doesn't mean anything, its just an empty buzzword being dropped into a product description that communicates no meaningful information at all. Even then, its seems to be intended to communicate "conforming to the REST architectural style", it just fails to do so because its done without any knowledge of the REST architectural style (and not even with an consistent wrong view such that the use of the term could be said to have a particular definition different from that that Fielding laid out for REST.)
[0] Though, to be fair, it often does, although sometimes to only some particular part of it (and not always the same part) as opposed to systems that lack the part being focused on. This use is somewhat consistent with Fielding's, though it would probably be better to focus on naming the particular element.
>Not really the opposite. "RESTful", when it doesn't actually refer to Fielding's REST [0], generally doesn't mean anything, its just an empty buzzword being dropped into a product description that communicates no meaningful information at all.
Well, it instantly communicates: 1) over HTTP(S), 2) using HTTP queries (and verbs) 3) taking advantage of HTTP authentication, caching etc, 4) returning, more often that not, JSON.
That is, the important parts people care about.
Well, it instantly communicates: 1) over HTTP(S), 2) using HTTP queries (and verbs) 3) taking advantage of HTTP authentication, caching etc, 4) returning, more often that not, JSON.
That is, the important parts people care about.
>REST, in the form coined by Roy Fielding, is actually almost the opposite of what "RESTful" means today
Doesn't matter. Real world usage defines words, not original intended meaning or etymology.
Doesn't matter. Real world usage defines words, not original intended meaning or etymology.
If I wanted to take an idea that someone else named X and bastardize it and still call it X, I would use that same excuse you just used.
You could use that same excuse, but unless your use caught on and reflected how the majority uses the term, it wouldn't be the same case at all.
I don't think any "majority" even cares about REST let alone know it exists. I also don't see jargon as something that may or may not "catch on", I see it as a way to organize ideas in a professional area so as to ease precise communication. If my peers keep changing the meaning of jargon then it makes it harder for everyone to have meaningful and constructive discussion about our field.
This all can be avoided if people make it as a rule not to reuse names for a new concept Y that is already being used for concept X. What do you see as the reason to reuse names? Do you think we're running out of them?
This all can be avoided if people make it as a rule not to reuse names for a new concept Y that is already being used for concept X. What do you see as the reason to reuse names? Do you think we're running out of them?
>I don't think any "majority" even cares about REST let alone know it exists.
Obviously, as its a technical term, "majority" here refers to the majority of the respective technical audience, not the majority across all people.
>I also don't see jargon as something that may or may not "catch on", I see it as a way to organize ideas in a professional area so as to ease precise communication.
The best way to "ease precise communication" though is to use a term as it turned out to be used/understood by most people -- not to insist of its initial intended meaning (which in IT could be off by several decades to its modern use).
>This all can be avoided if people make it as a rule not to reuse names for a new concept Y that is already being used for concept X. What do you see as the reason to reuse names? Do you think we're running out of them?
The thing is, REST initially was some random thing some guy wrote. A person totally irrelevant in the grand scheme of things, not some standards body.
REST became a thing and got relevant only after it was adopted by a critical mass, and in the process people used it in different ways, adopted what they liked, etc. Those changes due to impact with real and different uses, reflect into what people call "REST" today.
Once we called "computers" actual humans doing computations [1]. Then it was some huge machines in corporations. Now we can even call our phones that. It would silly to insist that we should keep computers to its meaning at any fixed point in time.
[1] https://muse.jhu.edu/login?auth=0&type=summary&url=/journals...
Obviously, as its a technical term, "majority" here refers to the majority of the respective technical audience, not the majority across all people.
>I also don't see jargon as something that may or may not "catch on", I see it as a way to organize ideas in a professional area so as to ease precise communication.
The best way to "ease precise communication" though is to use a term as it turned out to be used/understood by most people -- not to insist of its initial intended meaning (which in IT could be off by several decades to its modern use).
>This all can be avoided if people make it as a rule not to reuse names for a new concept Y that is already being used for concept X. What do you see as the reason to reuse names? Do you think we're running out of them?
The thing is, REST initially was some random thing some guy wrote. A person totally irrelevant in the grand scheme of things, not some standards body.
REST became a thing and got relevant only after it was adopted by a critical mass, and in the process people used it in different ways, adopted what they liked, etc. Those changes due to impact with real and different uses, reflect into what people call "REST" today.
Once we called "computers" actual humans doing computations [1]. Then it was some huge machines in corporations. Now we can even call our phones that. It would silly to insist that we should keep computers to its meaning at any fixed point in time.
[1] https://muse.jhu.edu/login?auth=0&type=summary&url=/journals...
> The best way to "ease precise communication" though is to use a term as it turned out to be used/understood by most people -- not to insist of its initial intended meaning (which in IT could be off by several decades to its modern use).
How do we know we're up-to-date with the latest definition? And what if someone disagrees with what is the latest definition? How do we even know what "most" people think is the latest definition? Do you see how your suggestion is unrealistic?
But, your next argument is the strongest here, and I stand corrected. I like your computer example. So I'd say if we deprecate the thing that the word meant before (human computers, or REST as defined by one guy and never used) then it's OK to reuse it. I don't know the REST story and have no reason to doubt your version of it, so thanks for the argument!
How do we know we're up-to-date with the latest definition? And what if someone disagrees with what is the latest definition? How do we even know what "most" people think is the latest definition? Do you see how your suggestion is unrealistic?
But, your next argument is the strongest here, and I stand corrected. I like your computer example. So I'd say if we deprecate the thing that the word meant before (human computers, or REST as defined by one guy and never used) then it's OK to reuse it. I don't know the REST story and have no reason to doubt your version of it, so thanks for the argument!
To be very accurate, REST isn't necessarily based on HTTP. But we like to see "REST" or "RESTful" as the type of HTTP APIs we almost all build nowadays as opposed to other protocols built on top of HTTP like SOAP. (Frankly, who builds non-HTTP REST stuff?!)
Disclaimer: I'm a Paw guy (founder).
Disclaimer: I'm a Paw guy (founder).
I am looking at it and can hardly find anything that it has that free POSTMAN doesn't have. I am wondering, anyone who leaving nice comment about Paw, have you used POSTMAN before, if yes, what is it what it miss that justify non cross platform piece of software that you have to pay for?
Not requiring Chrome is worth $15 alone.
Only if you're someone that doesn't use Chrome.
I use Chrome. I still don't want to use the idiotic "Chrome Apps" that aren't apps at all, when I have a choice. For certain tasks I can see the value, but for things I use every single day a native app is much better (especially just for battery usage, assuming decent coding for both versions).
Not necessarily - plenty of people who use Chrome also prefer native apps.
There are some benefits to being standalone but I'm not sure if any being a chrome app.
A native GUI? Believe or not people will still pay a premium for that, myself included. There's a lot of money that web app makers are leaving on the table by not making "non cross platform pieces of software".
It's excellent. It's worth the money. I didn't even expense it because it was worth my money.
I just discovered PAW yesterday. Its already my favorite Mac app. Absolutely wonderful!
I use Paw a bunch and I love it.
I normally use Postman, and the one feature that turns me off right now is the inability to import from a URL. Specifically, Swagger.
Postman has these type of import options: https://dl.dropboxusercontent.com/spa/4moihw0kt47f2sy/lona1q...
I also tried saving my Swagger JSON spec to a file and importing it via the Swagger Importer, but it failed. =\
Otherwise, it seems gorgeous!
Postman has these type of import options: https://dl.dropboxusercontent.com/spa/4moihw0kt47f2sy/lona1q...
I also tried saving my Swagger JSON spec to a file and importing it via the Swagger Importer, but it failed. =\
Otherwise, it seems gorgeous!
Hey, are you using that Swagger Importer? https://luckymarmot.com/paw/extensions/SwaggerImporter If it fails, I'm happy to help. Can you share with us the Swagger file you're trying to import ([email protected])? Will be happy to help.
(I'm the Paw founder)
I wish you could send a request by hitting the enter key in paw. I seem to remember that not being possible.
You have to do Cmd + Enter to send the current request
For the record, this is also common behaviour in other apps on Mac.
I downloaded the trial, but unfortunately it seems to be extremely buggy. I'll stick with Postman.
Sorry for the trouble :( If you can, we'd love to hear more details about the bugs you had. You can contact us via our support page: https://luckymarmot.com/paw/support Thanks a lot!
[deleted]
Might be nice. However, I do not find video an acceptable medium for a tutorial or documentation. Might be easier to make than a written doc, but so much harder for the recipient to get value out of.
This should have Swagger import!
There is an elementary particle physics program produced by CERN called PAW, for Physics Analysis Workstation.
In my honest opinion, it is the very worst computer program to have ever walked the earth.
In my honest opinion, it is the very worst computer program to have ever walked the earth.
Yeah, there are a couple of homonyms :) Didn't know that CERN project, though. We try to spell Paw (capitalized P) as it isn't an acronym.
the logo of Paw is too like Baidu's https://www.baidu.com/
A paw print is quite a generic thing and even the shape of the paw itself between the two is made differently. Aside from the general idea of a paw, they don't seem to have anything else in common.
Not in the MAS? I'm significantly less likely to buy your app.
Edit: apparently it is available via MAS but there is ZERO mention of this on the site (on mobile at least).
Edit: apparently it is available via MAS but there is ZERO mention of this on the site (on mobile at least).
Why? Sandboxing?
After a decade or more of Mac apps working just fine through online sales, what is the driver - what is so significant - that makes you get so upset that it might not be offered on the MAS?
I personally find the move to the MAS a sad development - less $ per sale to the dev, 30% grift from Apple, as if they needed more money, and sandboxing that renders some of the best apps out there less-than-useful. Not to mention Apple's arbitrary approval process that - if nothing else - puts an additional week between me and bug fixes.
I can understand liking the convenience. But what makes it so necessary?
After a decade or more of Mac apps working just fine through online sales, what is the driver - what is so significant - that makes you get so upset that it might not be offered on the MAS?
I personally find the move to the MAS a sad development - less $ per sale to the dev, 30% grift from Apple, as if they needed more money, and sandboxing that renders some of the best apps out there less-than-useful. Not to mention Apple's arbitrary approval process that - if nothing else - puts an additional week between me and bug fixes.
I can understand liking the convenience. But what makes it so necessary?
As lobster_johnson mentioned, Paw is indeed available on the MAS:
https://itunes.apple.com/app/paw-http-rest-client/id58465320...
I'm the founder of Paw, and frankly I like the MAS. It gave Paw a lot of visibility without us taking any financial risk. Otherwise, we would have needed to pay for some kind of advertising when we didn't have the money for it. MAS allowed us to bootstrap and gain users.
Sure, the 30% split for Apple sounds like a lot, and it surely is. That's exacly why we encourage users to get Paw from our website (which uses Stripe for CC processing). Also, website purchases get updates a little faster, as it doesn't rely on Apple's approval (which is IMO the real pain point of the MAS).
Lastly, sandboxing isn't an issue at all for us. And the version distributed through the website is also sandboxed. I personally love sandboxing, as a user first, and as a developer too. Sure, some apps (due to their nature) can't work with sandboxing, and should probably be allowed on the MAS as a special exception (the example I have in mind is the excellent Git Tower).
I'm the founder of Paw, and frankly I like the MAS. It gave Paw a lot of visibility without us taking any financial risk. Otherwise, we would have needed to pay for some kind of advertising when we didn't have the money for it. MAS allowed us to bootstrap and gain users.
Sure, the 30% split for Apple sounds like a lot, and it surely is. That's exacly why we encourage users to get Paw from our website (which uses Stripe for CC processing). Also, website purchases get updates a little faster, as it doesn't rely on Apple's approval (which is IMO the real pain point of the MAS).
Lastly, sandboxing isn't an issue at all for us. And the version distributed through the website is also sandboxed. I personally love sandboxing, as a user first, and as a developer too. Sure, some apps (due to their nature) can't work with sandboxing, and should probably be allowed on the MAS as a special exception (the example I have in mind is the excellent Git Tower).
It's good to have your view on this, but I honestly think you should make some reference to the MAS on your site - even if it's on a page that highlights the user downside (slower releases etc) - if I browse an app site/page and it doesn't mention the MAS I assume they're not on it.
Probably, yes. Thanks for your feedback anyways! There is a (not so visible) doc page about the differences: https://luckymarmot.com/paw/doc/Difference_MAS_Retail
I absolutely understand why developers don't like it - I wish Apple worked so they did so more stuff would be there. For me it's the sandboxing on small utility apps, and I admit I'll look in the store first. It's just peace of mind really, if an app doesn't need out the sandbox (I acknowledge many many apps do) then I'd rather have it contained.
See flashlight apps with absurd permissions and spyware on Android to see what assholes occasionally do with too many permissions.
See flashlight apps with absurd permissions and spyware on Android to see what assholes occasionally do with too many permissions.
> I can understand liking the convenience. But what makes it so necessary?
I said it makes me significantly less likely to buy it - specifically because of two factors: the convenience, and the security of knowing who is charging my card.
I didn't say "I won't buy this if it isn't in the MAS" - so what part of what I said means the MAS is "necessary"?
> I personally find the move to the MAS a sad development -
I didn't say everyone should be forced to use the MAS. Neither did Apple. Nothing stops a developer from releasing their App on their own and via MAS.
> less $ per sale to the dev, 30% grift from Apple, as if they needed more money
70% of $40 is less than 100% of $0?
> and sandboxing that renders some of the best apps out there less-than-useful.
Not to mention that pesky security it provides for end users.
Seriously, if an app can't operate within the sandboxing of the MAS, its completely reasonable for it to be not sold that way.
This app can operate within a sandbox, so why do you have such a problem with someone else wanting/using a more convenient and secure option?
I said it makes me significantly less likely to buy it - specifically because of two factors: the convenience, and the security of knowing who is charging my card.
I didn't say "I won't buy this if it isn't in the MAS" - so what part of what I said means the MAS is "necessary"?
> I personally find the move to the MAS a sad development -
I didn't say everyone should be forced to use the MAS. Neither did Apple. Nothing stops a developer from releasing their App on their own and via MAS.
> less $ per sale to the dev, 30% grift from Apple, as if they needed more money
70% of $40 is less than 100% of $0?
> and sandboxing that renders some of the best apps out there less-than-useful.
Not to mention that pesky security it provides for end users.
Seriously, if an app can't operate within the sandboxing of the MAS, its completely reasonable for it to be not sold that way.
This app can operate within a sandbox, so why do you have such a problem with someone else wanting/using a more convenient and secure option?
That you know the charger of your card is the argument that resonates the most with me. That's fair, and a solid reason to use a processor like Stripe - recognizable and near normal processor fees.
> "70% of $40 is less than 100% of $0?"
This is a terrible, terrible argument for being shoehorned into giving up 30% of your revenue. Stripe (et. al) charge, say, $0.30 + 3%. Add in binary hosting fees and we're at 30%? Again, I understand the CC argument, but this is very much an argument about how I (or someone else) should appreciate your business in whatever form it comes to me, and that's not true. You'll probably want point releases and features and customer support, but for 30% less than a sustainable price.
(Note that I'm not allowed to charge 30% more on the MAS to pass on the cost... That's a violation of the MAS developer agreement.)
> "70% of $40 is less than 100% of $0?"
This is a terrible, terrible argument for being shoehorned into giving up 30% of your revenue. Stripe (et. al) charge, say, $0.30 + 3%. Add in binary hosting fees and we're at 30%? Again, I understand the CC argument, but this is very much an argument about how I (or someone else) should appreciate your business in whatever form it comes to me, and that's not true. You'll probably want point releases and features and customer support, but for 30% less than a sustainable price.
(Note that I'm not allowed to charge 30% more on the MAS to pass on the cost... That's a violation of the MAS developer agreement.)
> That's fair, and a solid reason to use a processor like Stripe - recognizable and near normal processor fees.
As a user I don't get to choose which payment processor a developer uses.
> but this is very much an argument about how I (or someone else) should appreciate your business in whatever form it comes to me, and that's not true. You'll probably want point releases and features and customer support, but for 30% less than a sustainable price.
You're ignoring the higher likelihood of purchase via the MAS. When I can just click and its purchased without hassle, without issues, you have to deal with a lot less lost sales due to hard/troublesome/scary payment processes.
If you don't want to sell on the MAS, thats absolutely your choice as a developer, but you need to recognise that the MAS is a much better experience for buyers than pretty much any other option currently in use. The best case scenario is a seller who has an easy buying workflow, actually handles security correctly, uses a reliable payment processor, and gives me the required licensing information instantly.
I've not seen that very often, and even when I do, I'm still left having to manage my license information so I can easily re-install.
As a user I don't get to choose which payment processor a developer uses.
> but this is very much an argument about how I (or someone else) should appreciate your business in whatever form it comes to me, and that's not true. You'll probably want point releases and features and customer support, but for 30% less than a sustainable price.
You're ignoring the higher likelihood of purchase via the MAS. When I can just click and its purchased without hassle, without issues, you have to deal with a lot less lost sales due to hard/troublesome/scary payment processes.
If you don't want to sell on the MAS, thats absolutely your choice as a developer, but you need to recognise that the MAS is a much better experience for buyers than pretty much any other option currently in use. The best case scenario is a seller who has an easy buying workflow, actually handles security correctly, uses a reliable payment processor, and gives me the required licensing information instantly.
I've not seen that very often, and even when I do, I'm still left having to manage my license information so I can easily re-install.
Obvious solution - put the app up on the mac app store at 30% or so higher cost, and keep it around on Stripe or similar for those who want to buy it for less. Seems win-win.
Apart from breaking the rules for MAS publishing it's also dishonest - it doesn't cost $0 to self-distribute, but no one ever itemises that cost as extra
> (Note that I'm not allowed to charge 30% more on the MAS to pass on the cost... That's a violation of the MAS developer agreement.)
Is having some kind of rebate coupon after buying from a different payment processor an option? Or maybe increasing the price by 30% all around, and then throwing in some sort of 'added extra' for people who don't buy through the MAS?
Also, I like the MAS even less after learning about this kind of terrible control.
Also, I like the MAS even less after learning about this kind of terrible control.
Otoh with MAS you get: hosting, payment processing, easy notification of updates for the users.
As a user I love that when I get the new machine I don't need to go hunting for all the apps I own, looking for the download link again, then looking for the serial numbers/licences. I can just go to App Store app and click "Install".
The Mac App Store sucks for both users and devs. It cripples apps by making it harder for developers to add features.
That said, it is in the Mac App Store.
That said, it is in the Mac App Store.
https://itunes.apple.com/us/app/paw-http-rest-client/id58465...
(Not my app, by the way.)
(Not my app, by the way.)
Don't get me wrong, Paw is a really nice app, but I don't feel that it rivals the productivity of bash-jitsu for most day-to-day use.