Jump to content

Search the Community

Showing results for '길음역텍사스위치오라 카이 인사동 스위츠[Talk:Za31]모든 요구 사항 충족'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Geocaching HQ communications
    • Geocaching HQ communications
  • General geocaching discussions
    • How do I...?
    • General geocaching topics
    • Trackables
    • Geocache types and additional GPS-based gameplay
  • Adventure Lab® Discussions
    • Playing Adventures
    • Creating Adventures
  • Community
    • Geocaching Discussions by Country
  • Bug reports and feature discussions
    • Website
    • Official Geocaching® apps
    • Authorized Developer applications (API)
  • Geocaching and...
    • GPS technology and devices

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Location

  1. @Mangatome Then from your perspective, we have not yet reached the limit of what we can do with lua if done correctly. What will need to be done is the following: The player app should be able to run one version of lua for all v1 cartridges (retaining compatibility, such as it is). We will run all v2 cartridges in the latest version of lua. When the player app requests a cartridge from the Wherigo API, the player app's current lua version will be included in the request. The Wherigo API is responsible for compiling a cartridge with the requested lua version. As long as the Wherigo API is updated prior to releasing an updated version of the app with a newer lua runtime environment, things will work as expected. In this manner, we can also deal with old versions of the app. (The Wherigo API reserves the right to tell the app when it is too old and must be upgraded.) Updates to the player app could include updates to either the lua environment or player app API. Because of this, once we expose an endpoint to a cartridge, it is fixed in stone and cannot be changed. I know how to version web-based APIs, but have not yet put time into determining how to version the player API. (In other words, we need to guarantee cartridges built in 2024 will still be able to run when the year is 2030--or even cartridges created in 2026 using a 2024 version of Urwigo.) I imagine we could just have an interface per player API version, which when upgraded will simply chain call into the newer method. As mentioned above, the Wherigo API's compiler service would need to load the compiler appropriate for the request. (I'll likely store a compiled cartridge when requested for the first time, then skip the compiling step during subsequent requests.) We will need to have living documentation that covers the player app's specification: lua versions, required libraries, and the player API (not only the part that allows interaction with the UI, but also that allows the subset of network features we desire). I would like cartridge state to be kept separate from the lua version if at all possible. I want to work on a more robust state management API. Other thoughts: I certainly don't mind exploring a version of player app that will allow cartridges to be written in C#. You definitely know player apps better than I: how difficult would it be to construct interfaces for the player app such that we could easily drop in different types of cartridges? Even if we stay with lua, that's my intent to preserve compatibility with v1 cartridges while continuing to update lua for v2 (unless we decide each cartridge's manifest can tell the player app the lua version against which it's supposed to run). My first priority is to everyone's security. I still would like to allow authors the ability to use network resources, so how about this idea? When an author wishes to use network resources, their cartridge can undergo review. Once approved, that particular URL scheme will be whitelisted for that cartridge. When a player app downloads a cartridge, it can also download the URL whitelist. The player API will expose a network layer whereby it will only allow whitelisted URLs to be called. In this way, we maintain security while at the same time giving authors the ability to consume network resources. As for in what the player app will be coded, I must leave that up those who will volunteer for the player app. My preference is for the environment to be something in which most people are familiar. That way, when some volunteers have to step away for a while, other people can take up the responsibility with not as much of a learning curve. My preference is MAUI or Blazor Hybrid. I know Groundspeak seems to like React Native (their Adventure Labs app is built using that), but Wherigo v2 is not going to be a Groundspeak project (though I still want Groundspeak's backing). For developing all this, I'll want public GitHub repos with a couple project leads (always more than one since we're all volunteers) set up to review and merge pull requests into the trunk. Anyone in the community can make a pull request. Whether we want these repos initially private is still a good question. I'm glad we're not all jumping into coding this. And some public news: I attended a mega event last weekend, and Jeremy from Groundspeak was there. We'll set up a time to talk with each other and see if I can get Groundspeak to agree to let the Wherigo Foundation run Wherigo if we can deliver.
  2. This is sort of off-topic, because It's not about an actual gadget cache . Last Friday, at a local caching event, some friends and I started to talk about unusual special equipment needed to find some geocaches. We speculated what kind of "special" (but not hopelessly unaffordable) equipment we have not yet seen as required for a cache. Soon, a Geiger counter was mentioned. We then had a good laugh imagining a gadget cache design like this: At the posted coordinates, you find a box, with a small Geiger counter + instructions. The task is to find a very small radioactive item within, say, 30 meter radius (in the woods, so essentially unfindable by chance), which holds the logbook (or coordinates of the location of the logbook). To make it clear, this is not a serious cache proposal, but it was super funny to fool around with the idea. But the really hilarious punch-line here is that less than 24 hours later, I first read about the incident in Australia where they really had to find a nano-sized radioactive item with radiation counters ! You can easily google it, but for reference, here is one news link: https://www.bbc.com/news/world-australia-64481317
  3. 95% of couch logs so far are from very experienced players so this behavior is unlikely to be grounded in confusion about proper logging guidelines and ethics. Interestingly some are the same accounts who like to talk about game integrity in the forums The game contains this disclaimer in different locations: There's no mention of completing this game allowing players to claim a find on the respective cache. While we will try our best to curb couch logging, cheaters only cheat themselves, and it's on all of us honest players to advocate for proper gameplay in the channels at our disposal
  4. Perfect, thank you! I'd missed that one. I spent a lot of time looking at airports back when I first started this list, but now I usually don't go back to a given airport unless one of the existing caches on my list has been archived. For Munich, I know I haven't looked at the map in at least a year. I admit, I struggle with puzzle caches. If it's easily solved, then no problem. But for many, the language barrier is too much for me to overcome. So I usually rely on (robot translated) logs. The best ones are of course any that say, "We had a 4-hour layover at the airport, which gave us plenty of time to go looking for this cache and get back for our flight." Failing that, I look for logs that talk about finding the cache on their way to (or from) the airport. That's why I resurrect this forum post now and again, so I can get feedback from folks who have found the caches on the list. Which brings us to, if any recent finders of GC5PF9M or GC2ABTH have opinions on how feasible it would be to get to either of those caches from the airport terminal, I'd be glad to hear them.
  5. I am very interested in this project. I have always been an advocate for Wherigo and I personally have built a lot of them and have helped many others build them as well. While I am not a coder I can test, build, tear apart, and am willing to do whatever necessary to help bring some advancement to this issue. Also, I do have the ability and the platform to get the word out through our Podcast Network (Geocache Talk). this could be handy if we need more testers or builders or just want some feedback. I am very interested in this project. I have always been an advocate for Wherigo and I personally have built a lot of them and have helped many others build them as well. While I am not a coder I can test, build, tear apart, and am willing to do whatever necessary to help bring some advancement to this issue. Also, I do have the ability and the platform to get the word out through our Podcast Network (Geocache Talk). this could be handy if we need more testers or builders or just want some feedback. Memfis Mafia
  6. Interesting ideas all around. My 2 cents. I like the comment of Dani+Iris. Yes, it's tedious to maintain a physical location (although in my case it's not too bad honestly). On the other hand, there's plenty of examples of cartridges being (re)used outside of the original cache (the Hangman series in the US, the reverse Wherigo from Waldmeister). To attract a crowd for playing Wherigo's (isn't that what we all want), I feel the app/player experience is key. We (as builders) are obviously quick to point out the flaws/features requests of creating a Wherigo. But, in the end it's still the person that's loading a cartridge on his smartphone who's the boss. So what is it in Wherigo that can attract crowds over the myriad (successful or not) alternatives that have been launched? (I wish I had the answer to this.) Trying to dissect some of the ideas that were posted by Ranger Fox and others on the subject. 1. In general - I like the idea of having a map centric approach. It will put limits to how you can develop things, but I think it will give a much better experience for the player. - Videos: I do see use cases (eg. interaction with an NPC) but I would be deterred by the extra effort needed to create videos on top of building the cartridge. So for sure not a critical/v2.1 item for me. From that respect, Audio is more important. - Formatting of items to make it more appealing: text with different fonts/colors/..., different colors for the zones (if you still have those), ... 2. On Zones - Having a more 'stable' zone experience dealing with GPS-jitter - For most purposes, just a point is sufficient, but having a shape can be interesting (eg. I have one built on a roundabout, the zones are like a piece of a pie forming a complete circle; it's nice to have rectangles if you want to have a "gameboard" like experience) - I like the idea of having a picture/icon showing on the map, instead of just the zone shape. But we need to think about how to do it with overlapping zones/small zones (compared to the minimum picture size) 3. On NPC / Items - I like the idea of having a picture/icon showing. But we need to think about how to do it with many items on the same spot/in the same zone - I like the idea of not being forced to have these NPC/Items in a zone (or the inventory) for them to show up - Taking this one step further: what's the difference between a zone and one of these objects? From a logical perspective, not a lot (especially if you don't have shapes for zones). Only the options you have to interact with the Object might be different ("add to inventory" or "use" for Items, "talk" is typically something for NPC). 4. Online or not? - I do see the advantage of being able to play it offline. Trust me, as a European without decent/affordable data plans outside of Europe, it can become costly when visiting the US or other territories. - I like the idea of having a neatly integrated system with APIs to load a cartridge, post a "log", mark completion, ... 5. On Groundspeak/GC links - With the adventure labs, it's going to be difficult to sell a tour guide like Wherigo platform on them - From the GC posting guidelines: "specific apps" are not allowed. So they can easily block/disallow them. https://www.geocaching.com/help/index.php?pg=kb.chapter&id=97&pgid=297#mobileapps A small remark on this: yes, it's (more) work to create a Wherigo than just drop a pill bottle behind a tree in a forest. But I am sure some people put equally (if not more) time in building great cache containers, multi's, gadgetcaches or mysteries. That being said, to buld a community, you'll need "many" cartridges (of high quality), so you'll need many builders too. SWIPEE
  7. I'll add one that's been present for several years now. When a PNG or GIF image is uploaded to a cache page, the contents of the file are quietly changed to progressive jpeg with no warning and no change to the file suffix. There are plenty of puzzle caches that rely on these file formats, for example where the solution is encoded in RGB values, yet this behaviour isn't even documented in the Help Centre, leaving unwary COs oblivious to the fact that their carefully crafted PNG or GIF file has turned into a jpeg without even the .JPG extension to suggest anything's changed. The only explanation given for this is that, for players on slow internet connections, it looks prettier for images to gradually come into focus than to be built up raster-fashion. Talk about form over function!
  8. Be welcome! I would suggest that you do some caching for a while, attend some Events and talk to folks there... I bet all (almost) your questions will be answered just by playing. On the other hand you may be interested also in some geocaching based books and movies or series, like Splinterheads, Dark, etc. Some rare geocoins would be good things to leave in the caches, or memorabilia from pop culture, like the original artifacts in the APE Cache series, from Planet of the Apes. Enjoy and be inspired. PS: I have done a lot of covers for the portuguese versions of Goosebumps, from R. L. Stine.
  9. Yeah color me unimpressed lately with HQ. I definitely see them less as stewards now and more of a corporate machine that does not care about us, only about the bottom line. They talk a good game, but killing benchmarks and then messing up the search function and telling us "Sorry, we are on vacation and will get around to it when we get around to it" has me completely put off. At least I can go find a ton of adventure labs with little to no effort from a parking lot somewhere. What an adventure.
  10. Atlas, I understand your collection. I also know you realize the difference between using them and collecting them and are prepared to use bespoke software if you can get it at all. (Good luck with that Magellan stuff that required online registration, for example.) Mineral, close call! The 600 was actually the last device that I purchased when it was substantially discounted. The 450 it replaced had gotten crash-happy. The 600 at least rebooted more quickly when it crashed. By the time I purchased it, my own geocaching was largely limited by my own health and available time to business travels when I was "stuck" out of town. South SF Bay had enough geocaches to keep me occupied and there was enough flat land that I could choose my own adventures to tailor my days to my pain level for the day. I think I probably have a thousand or more finds that I've not even logged when I cached in part of a group on GeoWoodstock weekends, but I'm pretty much a former geocacher at this point. Thanx, user13371. For a few years after my surgeries, I was "frownie face" most of the time. While I still can't predict how much time I can devote to software just due to the nature of spinal issues, I do have some random lucid hours from time to time, so I can still pop out a release or two a year even if working from the bed or something. It's just the nature of my disability. The removal is in https://github.com/GPSBabel/gpsbabel/pull/961. Once I get that build green, I'll push it and it'll be gone in the nightlies and all future builds. For some reason, the doc build is silently failing on my machine right now and I don't feel like debugging that. I'll just "spray and pray" in the build cluster at Github. Once that PR is submitted, it shall be done. In vaguely related news, the birthdate of GPSBabel's original code turns drinking age this week. It was just before the Christmas holiday in 2001 when I was still in a neck brace from my very first spinal surgery (the morning of 9/11) when I started geocaching. I had a DNF from mistyping the coordinates in my Map330 and I started writing code to talk to the device from SCO UNIX after being frustrated with the tools available at the time.
  11. A lot of talk here about COs not using the OM log. My irk is when COs use the OM log to say. "I'm going to fix the problem." Case in point, a location I pass frequently when traveling where the cache has been missing for 8 months and the CO is doing nothing but posting bogus OM logs.
  12. I occasionally look through my old finds, and noticed that I am the last one to find dozens of caches. In fact, I made a spreadsheet of caches for which I am the last to find, and I have now recorded 130 caches. I was thinking this could be a good Challenge Cache. Of course if you just went on a big Geo Trail and found 100 caches that might be unfair, so I could put certain date parameters on it like one of the following: "To qualify for this challenge, you need to be the last finder on 100 caches and the most recent "last finder" cache must be at least 30 days ago." or "To qualify for this challenge, you need to be the last finder on 25 caches and the most recent "last finder" cache must be at least 6 months ago I would like some feedback if the community thinks this would be a good idea for a Challenge cache. If people think this would be a cool idea, who do I talk to about writing the code for it?
  13. Another way to work around it would be to block cookiebot.com, say at the firewall or HOSTS file. I've done this for a few years, and the site works fine for me, including the message center. Also keeps the site from asking me about cookies, don't ever talk to me about cookies.
  14. Not a naive assumption, but, yes, I did take for granted that you hadn't talked to the COs because if you already had reactions from the COs, I would expected you to present those in order to make that the topic. The responses you've now told us about are the real problem that we can talk about solving. It's far less productive to start with the unsupported claim that the NM attribute is useless because you don't think it's being used correctly. But, I see, this way you got to call someone innocently trying to help you with your problem "naive", so that's always fun.
  15. I am glad our countless hours of research through logs and plethora of photos mean nothing to HQ and zero attempts are being made to keep our data available in an archived format. All this community talk is nothing but lip service to the corporate machine and bottom line.
  16. If this is based truly on non use (vs cost cutting which I believe it is) then get rid of other things in geocaching that get little use such as caches that require special equipment such as Wherigo or project APE caches. You guys talk out both sides of your mouth!
  17. Looks to me that the proposed category is very similar to the elongated coins category (aka Penny Smashers) in the aspect of an automaton creating/selling a touristic token. T0SHEA told me (not a week ago) that we should strive for inclusion if we have similarities to another category. So you should have a talk to the category leaders / officers first if they are willing to expand their category to accept these touristic tokens also.
  18. We...don't do that here. That's not so much unholy as heretic. We don't talk about Mm-mm, no, no, no! We don't talk about Mm-mm! Grew to live in fear of Mm-mm being mentioned here Newbies post, thread is toast, moderators near I associate Mm-mm with the sound of locking threads (click, click, click) ...
  19. Yeah, I agree with you about that. That's one one the reasons I didn't seriously think he was interested in newbies: he was just using them as an easy way to talk about the perceived unfairness of challenges that allow history even though the newbies themselves wouldn't notice it.
  20. Regarding that we can also have a fourth option : 3a. Wayfrog promotes some other officer (perhaps the active one) and I have to talk again to the new leader. Or we could make it completely different and create a single category for each of the seven remaining countries (but for that option I would like to have a poll with at least two-thirds majority in favor for the split) ... Or something else that the community wants - just say it here. (This may include the (in my eyes really bad) idea to not have any new categories any more - but I think that should require a full approval with at least 95% of all waymarkers in favor ... And then we should close this recruiting part of the forum ... ).
  21. Better plan! Open enrollment is ON. Join, talk with our Wayfroggie about becoming leader. Throw out the deadwood. Invite some active Scandinavians to the group (there are a few here). Have one of them take it over, as a Scandinavian is a better choice as leader than a Canadian. Keith
  22. Since my response is to the moderators of the site and Groundspeak et al., I will post this here weeks after the main discussion has passed. Like all of my logs, this is mostly just a rant. I... support the decision! The sport/game/hobby of geocaching has existed for so long, its long term survival outweighs what some users think about the more antiquated elements of it. I would argue benchmarking is not a priority for many users, only partially because Groundspeak has relegated it to obscurity on the website for years. Beginners, who are important customers to expand the product, don't seem to be flocking toward benchmarks. My area has been dominated by loop-holers focused more on statistics than unique hunts and only seem to log benchmarks when they can get a challenge cache out of it. The 0.13% statistic that was paraded around is probably an understatement, but I do not see the logic of paying to support something so little of the general population cares about. A majority of my gripes are not with Groundspeak's decision but the rotten system of global capitalism and the myth of unlimited business growth. Low interest, sadly, equals low profitability and thus elimination. The archivist aspect is the main element that is tragic in all this, for me. But this is a symptom of the internet at large- huge portions of the web are just being lost to the wind and almost no one seems to care. Geocaching has now outlasted web 1.0, 2.0 and if the impending demise of twitter is any indication, 3.0 as well. One of its most valuable elements then are the logs from a pre-cell phone age. There are inactive users who commented on benchmarks and their logs will be lost forever. That sucks. While scraping page by page through The Internet Archive is a great idea, it's not practical. I'll try anyway. It's not a defense of the decision, but reality. Burying the lede here, but Benchmarking is/was one my favorite elements of Geocaching. I think it is profoundly interesting from a historical aspect, and many of my most memorable experiences with caching overall have been hunting remote benchmarks. I was annoyed with how old the datasheet was and just how many of the marks were actually destroyed. Especially living in an urban area, where mindless sprawl and that myth of unlimited growth have destroyed many of these disks. But the ones I did find were fun, even if it was impossible to combine that experience into any sort of phone application. Of the 84 I found so far, 56 (66%) have been radio/water towers, cupolas, domes, flagpoles, or just tall buildings. These are a majority of the benchmarks I've noticed other users have logged. Which is logical- they are the most easily accessible. But I would also argue, not entirely worth it. For those above me who complain about lamp post hides, these categories of benchmarking are very much in the same vein. I do not want to gatekeep against either as that would be hypocritical. I strive to give my logs as much depth and information as possible, but it's pretty obvious that a State Capitol dome is "in good shape". Which leaves the other 32 (34%) of my finds- bench mark discs themselves. This is what I'll- and others here- will truly miss. I think that the amount of marks logged as missing or never logged at all are vast. That sort of eliminates the ease of accessibility. Of those 32 disks, a third of them have been found less than five times. I am the most recent finder on all of those for the past eighteen months. I was happy to recognize one of those other finders in these comments, and empathize with their disappointment, but this doesn't eliminate benchmarking. It just pushes it to a much less popular website. This is by no means the end of my benchmarking. It's just the end of me keeping track of my benchmarking online- my disapointments with Waymarking are a separate rant entirely. Talk all you want about how the best things in life are worth the challenge, but from a business model perspective it's not marketable. Which goes back to my hatred of the "game" (capitalism) not the "player" (Groundspeak) trying to promote and protect Geocaching. So in summary, while I love benchmarking, I can understand why Groundspeak would phase it out. Because it's a niche, mostly unrelated element to geocaching at large.
  23. Three months is the bare minimum. I've had caches that were hidden for less, but it was not because I planned it - it was because they weren't viable for some reason and didn't work out. I have moved every couple years since starting, so each time I got to a new area, I knew roughly when the expiration date of my caches would be. I had a few in Oklahoma that I put out intending for them to be there for a year, and then we ended up moving six months early, so they were only there for five months. Other than that, looking through our hides, the shortest we planned to have some out was for about nine months. I'd say get 'em up now. If you end up moving next summer, take the ideas that worked and hide them in your new locale. I have returned to some hide styles (and some puzzles) over the years because they work, and because the locals don't necessarily know how to solve them in the new area. The important thing is to plan for your move. Don't wait until the last minute to try to adopt them out. Either talk to someone ahead of time about potentially adopting the listings from you, or plan to pick them up and archive them. Don't just leave them behind without a plan. All caches need maintaining, and moving without a plan just dumps the problem on the local cachers (and reviewers) you're leaving behind.
  24. Thanks both for the responses. I guess what I was trying to get at is not so much the theme of the cache as the physical nature of it. As a kind of anti-example, we don't really have LPCs in Australia but I found one that I understand was very typical when I visited California a few years ago. It was under the skirt of a lamp-post on it's concrete pillar about 3 feet off the ground, in the middle of a carpark. I can imagine that caches like that are convenient for people with limited mobility because you can get right up close to it whether you do that in a car, a chair or on foot. I can also imagine that, even if they all had great reasons to bring you to carparks, the same thing over and over would be boring. So my curiosity is more about how you might make the hide itself both accessible and interesting (perhaps uniquely so) to someone who, for example, is in a wheelchair or has low vision. And yes, I'm well aware that every person's disability is different. I used to do education talks with someone who uses a wheelchair. She can walk a decent distance but it can be slow and tiring so she largely keeps to the chair. However, she quite enjoyed wheeling into a classroom and doing the talk, then finding an appropriate excuse to stand up and surprise the kids. We weren't there to educate on disability and inclusion but I think she taught a lot of kids a good lesson doing that.
  25. I purchased a number of such apps. Every one of them self-destructed. As a dev myself, though, I'm somewhat sympathetic to their problem. There are a few problems that inherently makes the geocaching app market work poorly. I think it's gotten better for low-volume apps, but the OS provider (Apple, Google) gets a third of that right off the top. Now that's a fixed COGS and was hopefully built into the price model, but the dev now gets $6.50. The twist is that geocaching apps are something a user may stare at intently two days a week instead of, say, a joke-telling app that's used a few times and discarded or even something as specialized as a map converter that you only need a few times a year. Geocaching apps are just not typical App store apps: Geocaching apps are a small market. A successful app may have hundreds of installs and a really successful one may break into the thousands. So maybe that app maker made $10K. Maybe. (Download count is not the same as purchased user account...) It's a demanding market. Look at the endless raging controversy over 3 vs. 4 digits after the decimal point on some Garmin firmware. If your app works differently than the user expects, you're going to get an earful. Maybe you built - and sold as such - a bare-bones "follow the arrow" navigation app. You're going to get one star reviews because the app doesn't have native puzzle-solving abilities, such as decoding caesar ciphers on the device. That actually has nothing to do with geocaching, but there's an expectation that it's there. Maybe your app doesn't think it should be involved in travel bugs (and you made no promises about travel bugs in the app listing) but someone will say their life is ruined if your app can't automatically dip travel bugs with a log that auto increments, includes the timestamp, and reports "3/14 for the day", for each log. Oh, and it needs to handle the day ending when they went to bed, not at midnight because they were caching after dark. It's a moving target. Groundspeak was disrespectful of developer investment in their API and at least twice has restructured the way applications had to communicate with the server in an incompatible way. Not a minor, annoying, "let's change the spelling" way, but a major "rewrite the bottom half of the app" way. Multiple times. Cache types and log types and maximum API calls per hour and other things change (or at least did - I've quit following it) regularly. It's a localized target. Geocachers are worldwide. You'll need SI and Imperial. You'll need to know that altitude may be in feet, but ground distance may be in meters. You'll need at least most of the Romance languages supported. Individually these are trivial, but it's a lot of _stuff_ to keep track of and to exercise all the combinations. It's a changing target. Even within a given API level, Cache and log types come and go. Security rules around logins change. OSes change version and deprecate some service that you were using. There are new event types to handle. You'll need to build and test on phone and tablet, probably on real hardware and not the emulator because geocaching is a physical thing and it's hard to simulate the experience in the field. You'll need to handle all the new devices coming on as well as all the old devices that ever worked because someone will have a phone identical to yours, but is on a carrier that's withholding the OS upgrade so your "identical" phones offer two different sets of features to develop, test, and support. It's a demanding target. You don't control the schedule when any of this happens. OS updates get pushed and you're either on the train or your app quits working. Groundspeak changes the login process - again - and all your users are locked out. The solution space is small. You're never going to get VC funding to get an iOS dev, an android dev, a support person, a testing person, some equipment, etc. This is always doomed to be a one person operation (Every open-source attempt into this space I've seen has usually been a single-person show, perhaps after a brief flurry of introductory activity) and it's not like it's even going to be big enough money to be a full time job with insurance, etc. It's big enough to be painful (to do it well) but not big enough to actually hang a business around. Even Garmin made a run into the "geocaching" app space and eventually quietly withdrew. Not unique to geocaching is the split of the market. While there are frameworks that help you move your app between iOS and Android, they don't really cover things like the compass and the GPS and battery issues that are all crucial in a geocaching app, but less so in others. If you're a serious dev out to capture serious market share, you can then count on basically building,, testing, and marketing your app twice: Once in Swift and once in Kotlin. (And ten years ago, neither of those languages existed, so you've probably replaced the original Java and Objective C++ versions....) So now you're fighting for relevance in two markets, on two different fronts. I just looked at the android app store at the top paid apps from indy devs: #1 $5 - Sync for Reddit actually shares some of these problems. However, there are 430 million monthly Reddit users. The market is actually large enough to bring non-trivial income. Yay for them. Only they also just added monthly subscription fees ON TOP OF the base app price. This didn't go over well. #2 $3 calendar app. 1M users. (Hint: you're never going to get 1M geocaching app users) The target market is people that need a calendar. Not sure it competes on ongoing maintenance, though. #3 $1.39 watch faces. A watch face app is probably a weekend project. Build it once and you're done. 10K users. #4 $4. An application to talk to ghosts. Seems unlikely to have much tech support demand or changes from ghosts going on strike. So all of these are apps with a WAY larger potential user base and either less ongoing required dev/maintenance/support costs, or an additional monthly subscription fee to cover that. Yet, if you build an app for $10 (the same app for $2 would drive you insane with looky-loos demanding support) users basically expect the app to keep working forever, but without an economy around it that supports this. Build a $2 fart app where the market is anyone that was ever eight years old and people will forget about the app in a week and you never hear from them again. A watch face app may get a cease and desist from Rolex about using their artwork (and that could be detrimental if executed, but you're out a weekend of development) but you'll notice that other app types in the industry don't have this whole large ecosystem that they have to live in, but can't control. Mobile apps blew out the pricing of software. People now associate app prices with that $2 fart app, a $4 flashlight app, or the $1.39 watch face (honestly, I think the market for that kind of junkware has kind of blown over, but it still cratered consumer expectation of paying for software) and if you ask them to pay $50 for a specialized mapping program or some other market-specific tool, it's like you're a baby-killer. Yes, I was there for the wailing every time Clyde rolled out a paid upgrade to GSAK...and watched him put up with users going to great lengths to avoid paying for those upgrades, but still taking up his time. This isn't the article I was looking for, but it cites a lot of related articles that touch on these topics. See https://www.sciencedirect.com/science/article/pii/S0167811619300473 So, yeah. A failed $10 geocaching app is just par for this course. Sorry. If I need credentials, I've been developing geocaching-related tools off and on since 2001. I've built at least two Android apps and one cross-platform GSAK-like app for cross-platform to prototype stage. I have geocaching-specific code in GSAK and in Google Earth (drag and drop a PQ into Google Earth Pro. Thats me.). I've studied this market and I've thought about it a LOT. Concluding advice: develop geocaching apps to scratch your own itch or do it for fun, but there's no money in it.
×
×
  • Create New...