Computer Guy

Computer Guy
Sunset at DoubleM Systems (DBLM.com), Del Mar, California

Tuesday, August 18, 2026

To be Open or Closed, that is the question...

 



what are the pros and cons of making my app ToBeWise™ Open Source?

Michael, open sourcing ToBeWise could be valuable—but I would not open source the entire product. I would separate the software, quotation database, brand, and production infrastructure.

What “open source” would mean

True open source means other people may use, modify, redistribute, and commercially exploit the licensed code. Merely putting the code in a public GitHub repository is not enough; it needs an actual open-source license. Once code is public, existing forks and downloaded copies cannot be recalled simply by making the repository private again.

Pros and cons for ToBeWise

ProsCons
Long-term survival. ToBeWise could continue even if its current developers eventually stop maintaining it.Anyone can create a fork. A developer could adapt the code into another quotations or wisdom app.
More development help. Outside developers could fix bugs, improve accessibility, and contribute Apple-platform features.Help is not guaranteed. You could receive few useful contributions while still managing questions, issues, and pull requests.
Greater credibility. Users can inspect how the app works and verify its privacy architecture.Product strategy becomes visible. Competitors can study the architecture, search implementation, and development direction.
Mission alignment. Making useful wisdom software freely available fits the philosophy of the product.Possible brand confusion. Forks may be mistaken for the official app unless trademark use is tightly controlled.
Developer publicity. The repository could introduce ToBeWise to programmers, founders, educators, and potential collaborators.Security preparation. Every secret, credential, internal endpoint, signing asset, and private data file must be removed first.
Better continuity with Griffin and future contributors. Contributions can be reviewed and preserved in one transparent project.Ownership questions. You must confirm that Double M Systems has the right to license every significant piece of code.
Possible security review. More people can inspect the code and report defects.Public scrutiny. Opening the code can reveal old shortcuts, technical debt, and vulnerabilities before anyone volunteers to fix them.

Open source would not prevent you from keeping an official App Store version, charging for future services, or offering premium content. But a genuine open-source license must also permit others to use the code commercially.

The important ToBeWise distinction

The current App Store description says ToBeWise is free and contains thousands of carefully curated insights across more than 200 topics, along with fully local, offline semantic search. It also states that the app collects no data. That suggests that the principal proprietary value is probably the curated wisdom collection, categorization, brand, and accumulated product judgment—not merely the Swift code.

I would divide it this way:

Make open sourceKeep separate and proprietary
Swift and SwiftUI application frameworkComplete master quotation database
Navigation and user-interface codeProprietary topic assignments and curation judgments
Local favorites and collections architectureProduction synchronization and administrative systems
Notifications and scheduling frameworkPrivate analytics or operational tools
Sharing featuresSigning certificates, API keys, credentials, and configuration
Search interface and generic search engineAny particularly valuable ranking or database-generation process
A small demonstration quotation setToBeWise™ name, logo, icon, and official visual assets

The open repository could include perhaps 50–100 public-domain or clearly usable sample quotations, allowing developers to build and test the app without publishing your complete collection.

The quotation database should have its own legal and licensing treatment. Copyright may protect sufficiently creative selection and arrangement of a database even when individual facts or short phrases are not protected; longer quotations can involve separate rights questions. Do not casually place the entire database under the software license.

Best license choices

MPL 2.0 — my preferred choice

The Mozilla Public License is a moderate form of “copyleft.” Someone who modifies an MPL-licensed source file generally must make that modified file available under the same license, while separate additions and larger works can remain proprietary. It also expressly excludes rights to the project’s trademarks.

This provides some protection against a company taking ToBeWise, improving the existing code, and keeping all those improvements private.

Apache 2.0 — easiest for broad adoption

Apache 2.0 allows commercial use, modification, redistribution, and closed-source derivatives. It includes an explicit patent grant and does not grant trademark rights. It is attractive when maximizing reuse and contributions matters more than receiving improvements back.

MIT — simplest

MIT is short and easily understood. It allows nearly unrestricted reuse, including commercial and closed-source reuse, provided the copyright and license notice remains.

When not to call it open source

If your position is:

“People may inspect and improve the code, but they may not create commercial competitors,”

then you want a source-available license, not an open-source license. All OSI-defined open-source software must permit commercial use.

Before publishing anything

First confirm who owns the source code written by you, Griffin, contractors, and any previous developers. Copyright initially belongs to the creator unless the work qualifies as work made for hire or the rights were transferred in writing. Paying someone to develop code does not, by itself, necessarily establish ownership of all copyright.

Then:

  1. Audit every dependency and its license.
  2. Remove the production quotation database, user information, credentials, certificates, tokens, and private endpoints.
  3. Create separate LICENSE, CONTENT_LICENSE, TRADEMARK, CONTRIBUTING, and SECURITY files.
  4. State that ToBeWise™ and its logo may identify only the official Double M Systems release.
  5. Require review before outside code is incorporated into the official App Store version.
  6. Decide whether contributions use the ordinary project license or a contributor agreement. Most small projects do not need a separate CLA, although one may be useful if future relicensing is important.

Apple would continue reviewing your official App Store release in the usual manner; publishing the source does not remove your responsibility for the safety, operation, content, and legal compliance of the distributed app.

My opinion

I would use a selective open-source model:

Open-source the Apple client code under MPL 2.0, include a small sample database, and retain the full quotation collection, ToBeWise™ brand, production infrastructure, and official App Store distribution under Double M Systems.

That captures the strongest benefits—legacy, transparency, collaboration, and mission—without giving away the most distinctive asset.

Because ToBeWise is currently free, there is relatively little immediate revenue to protect. The larger concern is preserving the integrity of the collection and the brand. Open more later if the community proves valuable. The reverse decision is much harder because publicly released copies cannot be withdrawn.


why not open source the quote database as well? I'm thinking about open source so that it can be translated into foreign languages, and for an android version etc. and these would need the databases of quotes and authors.

I actually think that's a much stronger argument, Michael.

When I answered before, I was thinking like a software company protecting its intellectual property. But ToBeWise is not really a software business. It's much closer to a knowledge commons or a long-term cultural project.

If your primary objective is:

"I want ToBeWise to outlive me and become the world's best curated collection of wisdom, in every language."

...then I'd seriously consider open sourcing both the code and the database.

The advantages become much larger

1. Translation

This is the biggest one.

Instead of you trying to create:

  • English
  • Spanish
  • French
  • German
  • Portuguese
  • Japanese
  • Korean
  • Chinese
  • Hindi
  • Arabic

...volunteers from each language community could do it.

A native speaker can almost always produce a better translation than a machine, especially for quotations.

Imagine:

ToBeWise Español

maintained by Spaniards and Latin Americans.

Or

ToBeWise 日本語

maintained by Japanese users.

That becomes possible.


2. Crowdsourced curation

Today you curate.

Tomorrow:

  • people submit quotes
  • others review
  • others improve categories
  • historians correct dates
  • scholars improve attribution
  • philosophers debate categorization

Wikipedia became enormous because of this model.


3. Android

Someone who loves Android could simply build

ToBeWise Android

without waiting for Griffin.

You would still maintain the "official" version.


4. New platforms

People might build

  • Linux
  • Windows
  • Web
  • Vision Pro
  • Kindle
  • eInk readers
  • Raspberry Pi
  • Home Assistant

...

without you ever asking.


5. AI

This may be the biggest opportunity.

Imagine AI researchers using ToBeWise as

"the world's highest-quality structured wisdom corpus."

Instead of training on random internet quotes,

they train on yours.

That could dramatically increase ToBeWise's influence.


But...

I would separate the data from the software.

The software is easy.

The database is where things get interesting.

I'd structure it something like this:

Quotes
Authors
Topics
Tags
Cross references
Translations
Sources
Notes

GitHub is actually very good at collaborative editing of structured data.

People submit pull requests.

Editors approve them.

Exactly like Wikipedia.


I would still protect one thing

Not the data.

The brand.

Specifically:

  • ToBeWise™
  • logo
  • icon
  • App Store listing

Anyone could create

WisdomDB

using the database.

But they couldn't call it

ToBeWise™

unless you approved it.

That's exactly how Mozilla works.

Anyone can fork Firefox.

Only Mozilla ships Firefox.


The philosophy

This is where I think ToBeWise is unusual.

Most open source projects say

"Here's our software."

ToBeWise could say

"Here's humanity's accumulated wisdom."

That's a completely different mission.


One concern

The only thing I'd think carefully about is quality.

Today, if someone submits:

"Live Laugh Love"

— Socrates

...you simply reject it.

Once hundreds of people contribute,

you need editorial governance.

Wikipedia has administrators.

Linux has maintainers.

Python has core developers.

You'd eventually need something similar.


My opinion

I think you're asking the wrong question.

The question isn't:

"Should ToBeWise be open source?"

It's:

"Should ToBeWise become the Wikipedia of wisdom?"

If the answer is yes, then I would absolutely open-source the database.

In fact, I think the database is potentially far more valuable than the software. SwiftUI will be obsolete in twenty years. Android, web frameworks, and AI interfaces will all evolve. But a carefully curated, multilingual, community-maintained collection of humanity's best ideas could still be growing a century from now.

That strikes me as being very much in line with what you've always said your goal is: to create something that helps people make better decisions, long after you're gone.

I cut you off to get a quick answer, but now i'd appreciate you taking the time and give me your best answer.

Michael, after considering your actual objective, I would open the quotation database as well.

My earlier caution assumed the main objective was protecting ToBeWise as proprietary intellectual property. But your objective appears broader:

Make ToBeWise available across platforms, languages, cultures, and generations.

For that objective, keeping the database closed would work against the mission. Open-source code without the quotations would give developers an empty container. The database is the enduring asset.

Strictly speaking, the software would be open source, while the quotation collection would be open data/open content. Open licenses allow modification, redistribution, and commercial use; that freedom is what permits independent Android apps, translations, educational projects, and other implementations.

The strategic model

ToBeWise should become two related things:

  1. The ToBeWise Open Wisdom Database
    A platform-neutral, multilingual collection of quotations, authors, topics, sources, translations, and editorial information.
  2. The official ToBeWise applications
    The iPhone, iPad, Mac, Watch, Android, web, and future versions approved and maintained under the ToBeWise name.

That distinction is important:

The apps are clients. The database is the institution.

An Android developer should be able to build a client without reverse-engineering the iPhone app. A Spanish-language editor should be able to translate the database without knowing Swift. An educator should be able to create a specialized collection without changing your official product.

The real reason for caution

The main obstacle is not competitors copying the database. It is that the database contains several different kinds of intellectual property, and you cannot apply one blanket license to everything.

Database componentRights situation
Author names, dates, nationalities and basic factsUsually factual information
Your topic classifications, selection and organizationPotentially your compilation authorship
Your annotations, descriptions and editorial notesOriginal ToBeWise content
Ancient or public-domain quotationsGenerally unrestricted, although a modern translation may still be protected
Very short phrasesOften not copyrightable in the United States
Longer quotations from modern authorsMay remain copyrighted
Community-created translationsMay be separately copyrightable
Existing published translationsMay belong to the translator or publisher
Logo, icon and ToBeWise™ nameTrademark and brand rights

The U.S. Copyright Office says names and short phrases are generally not protected by copyright, while sufficiently creative selection and arrangement of database material can be protected. It also defines a translation as a derivative work.

That translation issue is particularly important. Even when the original quotation is public domain, a modern published translation may not be. And when the original quotation is still copyrighted, making a new translation can require authorization from the original rights holder.

Also, even where displaying a quotation in your own app might qualify as fair use, that does not necessarily give you the ability to grant everyone else an open license to that quotation. Creative Commons explicitly cautions that a license applies only to rights the licensor owns or is authorized to license.

This does not mean the database should remain closed. It means every record should carry its own rights information.

My recommended licensing structure

1. Database: Open Database License 1.0

I would seriously consider placing the database structure, selection, relationships, IDs, and ToBeWise-created metadata under the Open Database License—ODbL 1.0.

ODbL permits anyone to:

  • Copy and distribute the database
  • Build apps using it
  • Modify and translate it
  • Use it commercially

But an adapted database that is publicly used must also be made available under ODbL. That means someone who creates a Spanish, German, or Japanese version would generally have to make that improved database available rather than taking the English collection, adding translations, and permanently closing the result. ODbL also permits distribution through systems employing technological restrictions when an unrestricted version is made available separately—useful when distributing through app stores.

That reciprocity is why I prefer ODbL for your purpose.

2. ToBeWise-created translations and editorial writing: CC BY 4.0

Your original annotations, biographies, summaries, explanations, and project-created translations could be licensed separately under Creative Commons Attribution 4.0.

CC BY permits sharing, translation, adaptation, and commercial use while requiring appropriate credit.

A stronger alternative is CC BY-SA 4.0, which requires adaptations to remain under the same license. However, that adds compliance complexity and can create questions when content is distributed through platforms employing digital restrictions.

3. Public-domain quotations: mark them as public domain

Do not claim a Creative Commons license over material already in the public domain. Mark it as public domain and separately license only the ToBeWise-created selection, metadata, annotation, or translation. Creative Commons expressly recommends this distinction.

4. Modern or uncertain quotations: record-by-record treatment

Each quote should be marked as something like:

  • Public domain
  • Permission obtained
  • Submitted by author under an open license
  • Existing Creative Commons license
  • Short phrase/no copyright claim
  • Rights review required
  • Excluded from open distribution

This is the one situation in which provenance becomes essential. It is not academic fussiness; it is the permission map that tells Android developers, translators, publishers, and educators what they may safely reuse.

5. Brand: retain complete control

The open licenses should explicitly exclude:

  • ToBeWise™
  • The app icon
  • Logos
  • Official product-page graphics
  • Any representation that a fork is the official application

Creative Commons licenses do not license trademark rights, and CC recommends a separate trademark policy.

A developer could create an app using the database, but could not represent it as the official ToBeWise application without permission. You could permit language such as:

Powered by the ToBeWise Open Wisdom Database

while reserving:

Official ToBeWise™

How the multilingual database should work

Do not make the existing iOS database file the public standard. It is probably too closely coupled to Apple technologies.

Use a platform-neutral source format, with generated SQLite databases for the apps. Every quotation should have a permanent identifier that does not change when it is translated.

A record should include at least:

FieldPurpose
Quote IDPermanent identity across every platform
Author IDLinks variants of the author’s name
Original textQuotation in its original language, where available
Original languageLanguage code
Source workBook, speech, letter, interview or other origin
Source locatorPage, chapter, date or other reference
Translation textOne or more translations
TranslatorPerson or published translation used
Translation statusDraft, reviewed or approved
RegionSpanish-Spain, Spanish-Mexico, Portuguese-Brazil, etc.
Topics and tagsYour existing ToBeWise organization
Rights statusPublic domain, licensed, permissioned or under review
Content licenseLicense applying to that specific text
Review historyWho approved or corrected it

There should be one canonical quotation record with multiple translations attached to it, rather than creating unrelated copies of the quotation for every language.

Several translations may be valid. The system should allow multiple approved translations when wording, rhythm or cultural context differs.

Machine translation can produce a useful first draft, but a native speaker should approve anything identified as an official translation. Quotations are unusually sensitive to small wording changes: a technically accurate translation can still lose the insight, humor, elegance or force of the original.

It should become multicultural, not merely translated

There is a larger opportunity here.

A worldwide ToBeWise should not be only:

English-language and Western quotations translated into other languages.

Language communities should also contribute the wisdom of their own cultures:

  • Chinese thinkers in the original Chinese
  • Indian philosophers in Sanskrit, Hindi and regional languages
  • Japanese writers in Japanese
  • Arabic scholars in Arabic
  • African proverbs in their source languages
  • Latin American writers in Spanish and Portuguese

English then becomes one translation among many—not necessarily the master version.

That would transform ToBeWise from a translated American app into a genuinely international wisdom project.

Open does not mean uncontrolled

Anyone should be able to propose a contribution. That does not mean anyone can alter the official database.

I would establish:

  • An editor-in-chief or editorial committee
  • Technical database maintainers
  • A lead editor for each language
  • A written quotation-selection policy
  • A written attribution and sourcing standard
  • Two-person review for translations
  • A correction and dispute process
  • Versioned official releases
  • A contributor agreement affirming that the contributor has the necessary rights

The official database could contain statuses such as:

Submitted → Verified → Translated → Language-reviewed → Approved

The public repository would show the history of every correction. That gives ToBeWise something it currently cannot easily provide: an auditable editorial record.

What you would be giving up

Opening the database means accepting several consequences:

  • Someone may create a competing or paid wisdom app.
  • Someone may build an AI product using the corpus.
  • Someone may create a fork you dislike.
  • Some contributors may demand time without providing much useful work.
  • Disagreements may arise over translation, attribution, ideology and inclusion.
  • Once a version is released under an open license, existing recipients generally retain those rights; you can change the terms for future releases, but cannot call back the copies already released.

The answer is not to prohibit these uses. It is to make the official ToBeWise version visibly better, more trusted, more carefully reviewed and more current than the forks.

Your strongest protection would be reputation and editorial authority—not secrecy.

A practical rollout

I would not release the entire existing database tomorrow.

Phase 1: Prepare

  • Confirm ownership of the database structure, annotations and contributed material.
  • Add stable quote and author IDs.
  • Add rights-status and source fields.
  • Separate the brand assets from the data.
  • Choose the software, database and content licenses with counsel.

Phase 2: Publish a rights-cleared initial corpus

Release perhaps 500–1,000 of the strongest, cleanest quotations:

  • Public-domain quotations
  • Clearly unprotected short phrases
  • Quotations for which permission exists
  • Fully documented authors and sources

Also publish the schema, contribution guide and database-generation tools.

Phase 3: Translation pilot

Select one language—Spanish would be a logical first pilot—and recruit:

  • One language lead
  • Several native-speaker reviewers
  • One technical contributor
  • One Android developer

The pilot should test the entire process, not merely produce translated text.

Phase 4: Expand

After the workflow works:

  • Release additional languages
  • Invite authors to license selected quotations directly
  • Create an Android reference application
  • Establish an international editorial council
  • Publish regular signed database releases

My opinion

I now think opening the database is more important than opening the iOS code.

Mobile frameworks will be replaced. Apple and Android interfaces will change. Today’s code will eventually become obsolete.

A rigorously curated, multilingual, open collection of humanity’s best practical wisdom could continue improving indefinitely.

My recommendation is:

Open the ToBeWise database under a database-specific share-alike license; license ToBeWise-created translations and annotations openly; mark each quotation’s individual rights status; retain exclusive control of the ToBeWise™ brand; and maintain a rigorously reviewed official edition.

That would reposition ToBeWise from being primarily an app into becoming an open global infrastructure for wisdom.

Wednesday, August 12, 2026

Kill a bug, birth a bug, at least. One step forward, two steps back.

 


It is well known that one often introduces a new bug when attempting to fix a different bug.  Working with ToBeWise this morning was another of those occasions. I thought it would be helpful to document the lesson.  Here's the interaction:

I pasted this proof of bug into the chat window along with the comment below:

User attachment

Me: another violation of the rule

        (I didn't have to be explicit about how the second line of this insight is word-wrapped or truncated because we have had many previous conversations about how to do it so it looks right)


chatGPT:

7:30 AM
Worked for 3m 17s

Fixed. The cause was horizontal clipping—not intentional truncation. The insight text is now constrained inside the card so it wraps completely.

Me:  I had seen this insight rendered properly recently. What changed to mess it up?

chatGPT:

7:34 AM
Worked for 1m 3s

The regression came from yesterday’s insight-counter work—not from the insight data.

To obtain accurate card-height measurements, I changed the card hierarchy in commit 76d23e9: a normal View became the outer layout container, with the touchable moved inside it. That altered how React Native calculated the text width.

An older style used “stretch plus outside margins.” It worked with the previous hierarchy, but under the new wrapper it allowed the text box to extend beyond the card, where overflow: hidden clipped it.

So yes: I inadvertently disturbed previously correct rendering while fixing the counter. The new fix uses an explicitly bounded width with inside padding, which is safe with the new hierarchy.


Me: that's all well and good, thank you for fixing that bug, but now we have something new cascading from that decision.  Here's what that insight looks like using the app on the Mac, using a version of the software just prior to your fix, using Share/Copy:


Me: and here's what that same insight looks like when displayed on the Home screen:


Me: and here's what it looks like on the author screen:


Me: what we have here are 3 different ways to display the same insight, and it seems to me that there should be only one consistent method. Why should there be such inconsistency?  And why should a simple request to count the cards as they appear on Home screen scrolling require a format change inside the card? Things are getting out of hand here.


chatGPT:

You’re right. Counting cards should never have changed the card’s visual structure, and the three surfaces should share one rendering contract for wording, typography, wrapping, and author placement. I’m mapping the Home, Author, and Share/Copy paths now so I can identify exactly where they diverged and what should be unified—without making another code change yet.

You’re right to call this out. I’m tracing the three render paths and the card-count change separately, because counting cards should never have altered how the insight itself is laid out.


chatGPT:
9:10 AM
Worked for 4m 34s

You’re right. The inconsistency is real, and counting cards should never have changed the card’s formatting.

I found three independent renderers:

SurfaceRendering method
HomeSmallQuoteContainer with Home-specific width, line spacing, and truncation
Author screenQuoteTextAndAuthor with different spacing, width, and selectable text
Share/CopyA separate square-image renderer that dynamically changes font size and line height

That explains the three appearances. Some line wrapping will naturally differ with available width, but the separate typography algorithms, colors, spacing, and sizing are unnecessary inconsistencies.

The card counter was attached by restructuring the Home card so its height could be measured. That changed the layout hierarchy and exposed the clipping problem. It was the wrong boundary: counting belongs in the scrolling-list code, not inside the insight card.

The proper correction is:

  • Create one canonical insight-and-author renderer shared by Home, Author, and Share/Copy.
  • Keep only the surrounding surface different—buttons, branding, and available card dimensions.
  • Use one typography and spacing specification everywhere.
  • Move progress counting entirely into the scrolling-list layer so it cannot affect card layout.
  • Add visual regression cases for this Joshua Brewer insight and the other troublesome long insights on iPhone and Mac.

I recommend the Home card as the canonical visual style, with responsive wrapping when another screen is wider. I have not made another code change yet; another isolated padding adjustment would only add to the problem.

9:14 AM


Me: I think there's another format not being taken into consideration: the "universal postcard" format used for posts to facebook, instagram, x, etc. Is that correct?

9:19 AM
Worked for 56s

Yes—but your first image is the “universal postcard” format. I referred to it too narrowly as Share/Copy. That same 900×900 image is used for Facebook, Instagram, X, copying, and other sharing.

More importantly, the postcard code is duplicated in several components, so even the “universal” postcard could vary depending on where sharing begins.

The complete set is therefore:

  1. Home scrolling card.
  2. Author/detail card.
  3. Universal postcard for Share/Copy/social media.

They should share one canonical insight-and-author renderer. Only the outer format should differ: responsive screen card versus square branded postcard. The wording, font family, relative sizing, spacing, punctuation, and truncation rules should come from one source.

9:20 AM

Me: ok, let's unwind the current card counting scheme completely. then make the Home screen display match the author screen display in all respects except length of the card. This will eliminate one unnecessary set of rules for displaying the insights. The universal postcard is a special case which we can deal with later. When you have Home and Author screen insight layouts identical, except for length, then we'll reopen the card counting feature.

------------------------------------

Comments and Lessons:

The bugs and inconsistencies were uncovered by asking for a feature that was completely unnecessary, but I wanted it anyway (the card counting on the home screen). That seemingly little feature took many hours of AI time, and even more of my time. Although it finally worked, it blew up something else. And now it's going to take more hours to unwind, and to fix the inconsistencies it uncovered. So be careful what you ask for! 

This is the challenge for solo operators. We can do anything we want, and many times that is not what we would do if we were CEO and had to approve a Product Manager's feature request. As CEO, my priority would be to achieve a steady state for the app, good enough to be an MVP, so that some initial product market fit could be tested. As CEO, I would have approved only ugly bug fixes, not inconsistencies, or the whim of a product manager. The only thing that matters is getting user feedback. And that requires getting users. As a solo operator, I can focus on getting users or playing with code, not both.

This is why debugging is so expensive and time consuming. It's important to test everything even though you only "fixed" one thing.  Sometimes, it's quite maddening!

Monday, August 10, 2026

How big is it?

I got curious, so I asked how many lines of code are in the ToBeWise app as of today, not counting blank lines, comments, libraries, databases, indexes, content, etc.  Just code:


In the App Store, Apple shows that the app consumes 63MB of storage total, including content, databases, indexes, and code. 

Of course it's not really important how many lines of code there are in ToBeWise. It's what they do, how they do it, and how well the entire package serves the user.  

That's what really matters and that's what keeps us focused every day.

Software is never done, here's why

I lost track of when I updated TestFlight with the latest version of ToBeWise™and definitely lost track of the individual changes that I made since then, so I asked my AI to update the TestFlight and list the changes since the last version, which was only TWO DAYS AGO:

The latest TestFlight is 80.2.09, following 80.2.08. Please check these changes:

  1. Notification Schedule

    • Changing any schedule setting should immediately start or restart the schedule.
    • The status should go directly to Active.
    • The old Not Started and Changed blocker cards should no longer appear.
    • The Frequency card should show all choices without scrolling.
  2. Get the Most from ToBeWise

    • It should begin with:
      • Why ToBeWise Matters
      • Four Ways To Use This App
    • “Four Ways” should open one card containing all four methods.
    • “Startup Insights” should no longer say “/CEOs.”
  3. Discover list screens

    • “Startup Founders/CEOs” should now say Startup Founders.
    • Lists should have the A–Z / # of Insights selector.
    • Counts should be right-aligned.
    • Sorting should work in both directions.
    • Classical Philosophers and Classical Ideas should have the correct screen titles.
    • Cards should end above the bottom navigation and scroll internally.
    • The elevator bar should be draggable.
  4. Profile information screens

    • Software Notes should have < back in the upper-left and the bottom navigation visible.
    • Privacy Policy, Terms of Service and Origin Story should wrap all lines correctly.
    • Their cards should end above the navigation and have draggable elevator bars.
    • ToBeWise blog should appear after the website link.
  5. My Metrics

    • More compact line spacing.
    • Card remains completely above the bottom navigation.
    • Watch Favorites and Watch Shares counts appear.
  6. Apple Watch and dashboard

    • Favorite and Share a quote from the Watch.
    • After opening the phone app, verify the counts reach My Metrics.
    • The dashboard should show Watch Favorite and Watch Share in both User Summary and Event Log.
    • Mac activity should be labeled simply Mac.
  7. Home screen

    • The Pause button spacing should look balanced.
    • On a Mac, automatic scrolling should stop when another app has focus and resume when ToBeWise regains focus.
So, that list represents the changes in the last two days.  This app was first programmed 10 years ago. You might think that it would be perfect by now. Not. Not ever. There is always more to do. First of all because we learn more by using the software... how to make it faster, more intuitive, simpler, and also because the environment changes continually... the target audience, the platform, user feedback, etc.

It's the law:





Friday, August 7, 2026

Apple Watch improvements

The new app icon looks a lot better on the Apple watch notifications, and that got me thinking about how I always wanted to have a watch app as a companion piece to the iPhone app.

This is step one, which allows Favorite, and Share direct from the watch. Neat.

This minimal update is automatic when the user updates the iPhone app. 

So easy!

---------------------------  Update August 9, 2026

Also updated the Management Dashboard and My Metrics to show watch Favorites and Shares.

Interesting: Apple only allows circular app icon for the watch, as opposed to the round corner square for the other devices.


Thursday, August 6, 2026

ToBeWise™ now aware of its own demise


A little feature I've wanted to add for some time is for the app to check if there is a newer version of itself available on the App Store, and if so, offer to download it now.

It's surprising how many users are getting by with older versions, and it kinda pains me to know they will not be able to use the neat features I'm adding.  

Starts with version 80.2.00, available soon, now waiting for review in the app store.

So this new feature is the one to rule them all.  (all future features)


:) 

ToBeWise™ now available as a Mac app

 In another miracle of modern technology, our favorite app is now available to run on the Mac.

The only caveat is that the Mac is Apple silicon, not Intel.


Search for tobewise on the App Store on your Mac and click the dropdown



Move the slider to the right, highlighting "iPhone & iPad Apps" and Bingo!