Apple-Monitor: a Java tool that pushes Apple store stock alerts to your phone

What Apple-Monitor watches and who it is for

Apple-Monitor is a Java implementation of an Apple store inventory monitoring tool that supports message push through Bark, Feishu and Lark robot webhooks. The project description states that it currently covers Apple stores in mainland China, Hong Kong, Macau, Taiwan, Japan and other regions, and the supported country list gives you the exact set: CN, CN-HK, CN-MO, CN-TW, JP, KR, SG, MY, AU, UK, CA and US.

The scope is narrow by design, and the narrowness is the feature. You tell it which product code you want, which country, which area and optionally which stores, and it polls Apple's store inventory for you and pushes a message the moment a match turns up. The product code is the internal Apple part number such as MTQA3CH/A, and the project links a model list for finding the right one. The optional store list is a fuzzy match, and leaving it empty means every store in the area is watched.

The audience is a person waiting for a specific configuration to become available. That is a distinct problem from general stock monitoring, because the interesting event is a narrow one: this colour, this storage size, this region, and in some cases this one physical shop. A tool that watched everything would be noisy, and a tool that watched everything but only reported general availability would miss the moment you actually care about.

The project is MIT licensed, the repository is not archived, and the last push was on 2026-09-24. The release history shows v0.1.3 from 2024-10-10, v0.1.4 from 2025-09-17 and v0.1.5 from 2026-09-23, so the tags are infrequent and the version numbers are still early.

The single config.json drives everything

The configuration surface is one file, and the structure is a top-level appleTaskConfig object.

Inside it, cronExpressions holds the schedule, and the documented advice is specific: set the interval to three seconds multiplied by the number of device models you are monitoring, and if you are not confident writing a cron expression, use the expression the program prints out as a recommendation. That is a sensible default, because the polling rate is what determines how quickly you see a change and how hard you hit Apple's endpoint.

The country key takes the country code from the supported list. The location key is your area, written in the address style Apple's own site uses, such as a district and a city, and the documentation says other regions should use a postal code instead. The deviceCodeList is an array of objects, each holding a deviceCode for the product you want, a storeWhiteList for the shops to watch, and a pushConfigs array with the notification settings for that model.

The push configuration object has four keys. barkPushUrl is the Bark server address and it defaults to https://api.day.app/push. barkPushToken is your Bark token, with a link to the project's own Bark usage note. barkPushSound is the ringtone name for the notification. feishuBotWebhooks is the Feishu bot webhook address and feishuBotSecret is the bot secret.

Two conventions are worth noticing. The location format follows Apple's own address style, so the tool can match against store records the same way the website does, and the per-device push configuration means two models in the same run can push to different destinations. The Japan and Korea notes also show that the country setting changes how location is interpreted, since both use postal codes such as 197-0804 and 01000, with regional example configurations provided in the project resources for those two countries.

Running the released jar

The documented path is to take a build artifact rather than compile it yourself. Download the compressed release archive from the releases page, unpack it, and you get an executable jar, a config.json file and some documentation. Edit config.json with the models and regions you want, then start it with `java -jar apple-monitor-v*.jar`, where the wildcard matches whichever release jar you unpacked.

That is the whole runtime story. There is no database, no web interface and no daemon to register, so the operational surface is one long-running Java process with a config file beside it. Which raises the obvious question for anyone planning to run this on a server, and the project answers it in the container image it ships.

The Dockerfile in the repository builds the jar with Maven and runs it on a JRE:

FROM maven:3.9-eclipse-temurin-17 AS builder
WORKDIR /app
COPY . ./
RUN mvn -B clean package -Dmaven.test.skip=true \
 && cp target/apple-monitor-*.jar /app/apple-monitor.jar


FROM eclipse-temurin:17-jre
WORKDIR /app
COPY --from=builder /app/apple-monitor.jar /app/apple-monitor.jar
CMD ["java", "-jar", "/app/apple-monitor.jar"]

Two details in that file matter. The build stage skips tests with -Dmaven.test.skip=true, so the image contains no test evidence about the code it ships. And the comment on the final copy line records the practical constraint, that the program reads config.json from its working directory and that you must mount it yourself, giving the example of mounting ./config.json to /app/config.json. Without that mount the container starts with no configuration and has nothing to poll.

The final CMD runs the jar from /app, so the working directory is the one the config has to land in.

Push delivery through Bark and Feishu, and the mismatch in the list

The supported push methods section lists two entries, the feishu bot and bark. The project description is broader, naming Bark, Feishu and the Lark robot among the supported push methods, and the topic of the repository name in the ecosystem, Lark being the international counterpart of Feishu, is why that wording appears.

The configuration keys tell you which are actually implemented. There is a barkPushUrl, a barkPushToken and a barkPushSound, and a feishuBotWebhooks and feishuBotSecret. There is no Lark-specific key, so if you were expecting a separate Lark robot configuration you would not find one in the file format. The Feishu webhook plus secret pair is the closest thing to a Lark robot setup, since Lark robots are configured with a webhook in the same shape, but the documentation does not spell that out, and it is worth checking before you assume a Lark endpoint works with the feishuBotWebhooks value.

The Bark side is the simpler of the two, and it is the one with a sound field. The default server address is https://api.day.app/push, the token identifies your device, and the sound key sets the ringtone. That last field only matters on iOS, where Bark plays the named sound when the notification arrives, and the value in the example is a CAF file name.

The Feishu side needs two values rather than one, the webhook address and the secret, which is the signed-webhook arrangement Feishu bots use rather than a plain posting endpoint. Both push mechanisms are configured per device model rather than globally, so you can route different models to different channels.

For anyone running this on a Windows machine, there is one documented snag: if the command prompt shows garbled characters, run `chcp 65001` first. That is a console code page issue rather than a bug in the tool, but it is the kind of thing that looks like a broken install.

Where Apple-Monitor is the wrong choice

The first limit is that it only tells you what you asked about. There is no watchlist of every model, no price tracking, no restock history and no notification when a store has a different configuration than the one you specified. If you want to know that a new colour exists anywhere, this tool will not tell you, because you have to name the product code and the model list it links is a reference rather than a catalogue it watches.

The second limit is the polling interval and the advice around it. The recommendation is three seconds per monitored model, which means a dozen models is a request every 36 seconds, and that is a rate you impose on Apple's store endpoints from your own address. The project is not doing anything to hide that, and there is no documented request ceiling, so a large watchlist means a lot of traffic from one IP.

The third limit is the store matching, which is fuzzy. The store white list is described as a fuzzy match, and an empty list means every store in the area is monitored. Both are the wrong shape for a large region, because a city with a dozen shops produces a dozen checks per interval and the notification may not distinguish which shop has the unit.

The fourth is the region coverage, which is fixed at twelve country codes. Any market not on that list is simply not available, and adding one would mean changing how the tool builds its store query, which is not a configuration change but a code change.

Compare that with the browser's own store page, which is free, needs no configuration and always shows current state. The difference in approach is that the browser requires you to be there, and the store inventory changes without notice, so the value here is that the check happens on a schedule and the notification arrives whether or not you are looking. That is worth a polling job and a config file. It is not worth it if you only want to check once in a while, and the project states that it is for study and research and forbids commercial or illegal use, which is a limit on the intended audience rather than a technical one.

Licence, releases and what to check before you configure it

The project is MIT licensed, with the LICENSE file in the repository root, which is one of the more permissive terms and allows commercial use of the code. The repository also carries a disclaimer stating that the project is for study and research, that commercial and illegal use is forbidden, and that the author can be contacted by email if a relevant company has objections. That is a statement from the author rather than a restriction in the MIT text, and the two are different things, so it is worth knowing which one you are relying on.

The releases are v0.1.3 from 2024-10-10, v0.1.4 from 2025-09-17 and v0.1.5 from 2026-09-23, and the last push was on 2026-09-24, so the current tag is recent even though the numbering suggests an early project. The version numbers have been at 0.1.x throughout, and the repository does not publish a home page, so the releases page and the issue tracker are the places to look.

What to check before you configure it is specific and short. Get the device code for the exact configuration you want from the project's model list, because MTQA3CH/A and its siblings differ by colour, storage and region, and a code for the wrong market will never match. Then decide between a postal code and an address-style location, since the documentation specifies an Apple-style address for most regions and a postal code for others, with Japan and Korea using postal codes such as 197-0804 and 01000.

Next, set the cron expression using the program's own recommendation rather than your own, since the recommended interval is derived from the number of models you are polling. Then fill in one push channel and leave the other blank, so you can tell which one is actually delivering. And keep config.json out of any shared storage, because it contains your Bark token and your bot webhook, which is the same reason the container image expects you to mount it as a local file rather than bake it into the layer.

Editorial conclusion

Apple-Monitor fits a buyer waiting for a specific iPhone configuration to appear at a specific store, who wants the alert on a phone rather than a browser tab, and who can supply a device code and a store name. It does not fit a buyer who wants a general price or availability tracker, because the tool checks only the product codes and stores you name, and it does not fit a deployment where the config.json cannot be kept private, since that file holds your Bark token and your bot webhook. Before you run it, copy the jar release rather than building from source, fill in the device code from the project's model list, and set the cron interval to at least three seconds per monitored model, which is the cadence the project itself recommends.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. MoshiCoCo/Apple-Monitor on GitHub
4. README
5. Releases